how to do spike/research story which can run more than 1 sprint



  • I past I have done a research/spike story which was a new area for me. Building big excel, debug ntml2 jar for authentication issue. our sprint was 2 weeks and it runs for more than 1 sprint, what Scrum says about handling such a story and how to timebox it if it can deprioritize. And story point nowhere converts to days. so if the story does not deliver in a sprint, team velocity will go down and management will get worried.



  • TL;DR

    A research spike is intended to reduce the cone of uncertainty for future work. It is not intended to deliver shippable increments of anything. Treating the output of a spike as anything other than input to story planning/refinement is a Scrum implementation smell.

    Time-Box Your Spikes

    As an empirical control framework, Scrum is heavily reliant on time boxes to create feedback loops and opportunities to inspect-and-adapt. A story spike is really just a specialized user story that provides just enough knowledge to plan a related backlog item. A spike should not be used to contribute directly to the current Sprint Goal, and you should strenuously avoid having same-Sprint dependencies on a spike.

    Spikes should have a maximum size of one Sprint, just like any other story. Each of the exploratory tasks for a spike should have an estimate on the Sprint Backlog, just like other Sprint Backlog items. You then handle spike slippage the same way you handle user story slippage: fail early. Tasks that exceed their Sprint Backlog estimates should be communicated in the daily stand-up, and the whole team (including the Product Owner) should decide what to do about spikes that won't deliver value or that can't be completed within their time-box.

    Decompose Your Spikes

    Spikes must fit within a single Sprint, and should be fairly concrete in their objectives. Building a large Excel spreadsheet, or debugging a complex library, are appropriate targets for a spike. Instead, you should consider the actual planning goals and develop spikes that answer targeted questions. For example:

    1. We need to build a large authentication table with 100 unique states, and we don't know how to estimate that story.

      • Let's try building a smaller sample of around 10 states in Excel, just to get a sense of how much work would be involved as we scale up!
      • We'll guesstimate 5 story points for the spike to build the scaled-down sample, and then use the outcome of the spike to improve our estimates for the full story next Sprint.
    2. NTLM authentication is broken, but we don't know how much work it will be to fix it.

      • Let's use the error message to find the method call that's a problem, and then tally up all the places in the library that call that method. That should give us a rough estimate of the size of the problem.
      • If we can identify the problematic method, we'll examine it as a team to get a sense of how easy (or difficult) it will be to fix it, work around it, or develop an alternative.

    In each case, the goal of the spike isn't to solve the problem. It's to define a problem, validate an idea, or scaffold a quick-and-dirty proof of concept. The only work involved should be just enough research to estimate the size of a related problem with unknown scope or difficulty.

    As currently described, you're treating spikes as "deliverable work of unknown size." Don't do that! You should be decomposing your spikes until they are small, targeted explorations that support planning and level-of-effort estimation of future work.

    Research is Work

    Spikes are work. All work for a Sprint should be estimated, prioritized, and planned. Therefore, time allocated to spikes should be counted against the team's capacity for the Sprint. However, the current Sprint Goal should not be dependent on the spike, nor should a "failed" spike imperil the Sprint. In fact, when properly done a spike really can't fail because its sole purpose is to reduce the cone of uncertainty.

    So, setting aside the question of whether you should be treating velocity as a productivity metric (hint: you shouldn't!), a spike completed within its planned time box is "done" and won't impact your real velocity. An incomplete spike that yields learning is also "done," and won't impact your velocity either. The only way a spike will drag on your velocity is if it's not started, or if it was not executed in a way that yields any sort of validated learning that narrows the cone of uncertainty for a future Sprint.

    Note that if the spike is somehow "not-done," then a team's velocity metric should be impacted. Otherwise, you're creating invisible work or hand-waving your Sprint Planning. Neither of these things will improve the efficiency or predictability of the project, which requires that potential drags on capacity be kept visible.

    Don't protect your velocity metric in a misguided attempt to sweep problems under the rug. Transparency is a requirement of Scrum, and velocity only works effectively as a detective control and capacity-planning tool when its an honest reflection of the work a team can likely complete within a single Sprint. If your spikes are legitimately dragging on the team's velocity, then that's an issue to address in the Sprint Retrospective for future Sprint Planning and Backlog Refinement activities.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2