Two items on the PI board had a question mark on them. Nobody knew whether the new payment provider’s API could handle partial refunds, and nobody knew how much of the old reporting module would survive the migration. So the team did the honest thing. It took in two agile spikes, timeboxed to three days each, and sized everything else around them. The team voted four fingers for 12 March.
Both spikes finished on time. Both answers were useful. The payment API needed an adapter: four new stories. The reporting module had to be split into three pieces of work, not one. The stories went into the backlog that afternoon. The roadmap still showed 12 March in green.
What an agile spike is
A spike in agile is a timeboxed piece of research a team takes on when it does not know enough to size or design an item. The term comes from Extreme Programming. A spike’s output is knowledge, not shippable product: a working prototype, a decision, a clearer picture of the work. SAFe treats spikes as a type of enabler and separates technical spikes (can this approach work, how will it perform) from functional spikes (how should the user experience behave). In Jira, a spike story is usually a story or task with a spike label or its own issue type.
Taking spikes into a PI is expert engineering judgment. It is the team saying which parts of the plan it understands and which it does not yet, instead of pretending to know. That candour is part of the evidence behind the confidence vote, and it belongs there.
The vote happens before the answer
The timing is the problem with every agile spike. The confidence vote is cast on the plan as it stands on day two of PI planning. The spike’s answer arrives in sprint one or two. Whatever the answer is, it changes the release, and it changes it after the commitment.
The answer arrives as scope. A spike rarely concludes “it’s smaller than we thought”. More often it returns new stories, a split, or a bigger re-size of the item it was investigating. Those stories land in the committed Fix Version the same day.
Nobody files a change request for it. The work was always “in scope” in the sense that the item was on the board. So the new stories go straight in, with no change control, no re-plan and no conversation about the date. The scope line climbs. The plan says nothing moved.
The answer often brings company. The payment adapter needs a sandbox account from another team: a dependency nobody had on the board. The migration work needs the one engineer who knows the old module: a capacity question. That is scope creep with the other two of the three things that erode a committed release date riding along behind it.
Keep the spikes. Re-price the date the day the answer lands.
The answer is not to avoid spikes or to pad the plan around them. It is to treat each agile spike as an open question in the forecast and close it on purpose.
- At planning, list each spike next to the item it unblocks, and record the committed date with the confidence level the team voted at.
- Schedule spikes in the first sprint, so their answers arrive while there is still margin to trade.
- Before the vote, agree what each plausible answer would add: “if the API can’t do partial refunds, that’s roughly an adapter’s worth of stories.”
- When a spike finishes, put the resulting stories, splits or re-sizes into the Fix Version that day.
- Read the gap in days between the committed date and the forecast at the committed confidence, the same day.
An illustration, not customer data. A release is committed for 12 March at 85% confidence. At the vote the 85% forecast sits at 9 March: three days of margin. In sprint one, the payment spike adds four stories and the reporting spike turns one story into three. The Fix Version grows by about 9%. Nothing else changes. The 85% forecast is now 20 March, eight days past the commitment. The 50% forecast is 11 March, so the release reads amber, not yet red. The spikes, meanwhile, are marked Done.
Now the conversation has a number on it. Push the reporting split to the next release? Drop partial refunds to a Could-have below the cut-line? Ask the other team for the sandbox this week, not next month? Renegotiate the date while there is still room? Every option is the team’s call. What changes is that the call happens in sprint one, not at the system demo.
Where Advanced Release Planning fits
Advanced Release Planning for Jira does not read spike labels, spike issue types or spike outcomes. It reads what a spike’s answer actually changes: the issues in the release’s Fix Version. Every issue added to or removed from the Fix Version, in the app or by changing the Fix Version in Jira, steps the burn-up scope line up or down, whether or not a change request exists. Scope growth is shown as a percentage and a per-day rate, and the Monte Carlo forecast is re-run against your delivered throughput. The committed date is reported against the 50%, 85% and 95% bands, with the drift in days. The team sets the assumptions: which throughput window, whose capacity, what is in scope. The app does the arithmetic at Monte Carlo scale and keeps it live. Green at or above P85, amber between P50 and P85, red below P50.
For the rules a team writes about controlling scope before the vote, see the scope management plan. For what happens when one card becomes several, see why new stories land above the release line. For exactly what the app reads when scope changes, see the project scope management reference doc.
Key takeaways
- An agile spike is timeboxed research that produces knowledge, not shippable product.
- Taking spikes into the plan is expert engineering judgment and part of the evidence behind the confidence vote.
- The vote is cast before the spike’s answer. The answer usually arrives as new stories, splits or re-sizes inside the committed Fix Version, with no change request.
- Schedule spikes early, put their results into the Fix Version the day they land, and read the gap in days against the committed confidence.
FAQ
What is a spike in agile?
A timeboxed piece of research or prototyping a team does when it lacks the knowledge to size or design an item. Its output is an answer, not a feature.
What is the difference between a spike and a story?
A story delivers user value. A spike story delivers information that lets the team plan or build the real story. Many teams track both in Jira and timebox the spike.
Can a spike move a committed release date?
The spike itself is usually small. Its answer often is not. If it adds stories or splits work inside the committed Fix Version, the date can move. Read the shift in days against the confidence level the team committed at.
Keep asking the hard questions. Keep the date honest too. See the committed date and its live confidence band in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.