How to Handle Unfinished Stories?
It is not uncommon for a scrum team to get to the end of the sprint and find that they have a story that has been worked on, but is not yet done. Perhaps the story appears to be about 80% done. What should become of such stories and how should the progress made on them be tracked? These are questions that every agile team will face. In a recent blog post, David Starr shares his approach.
One way to track progress is to give 80% of the point value of the story to the team for the current sprint. At first blush, this approach seems to accurately reflect the state of things, and may help keep the team's recorded velocity from varying up and down, sprint to sprint. It also has a certain amount 'feel good' value for the team. However, this approach has significant risk. The story is not verifiably done and the amount of time and effort that will be needed to get to 'done' isn't really known.
A second possibility is to split the story into smaller stories and take credit for the ones that can be considered done. To the extent that some of the smaller stories are truly 'done', this can reduce the risk associated with the 'partial credit' approach. It also allows the product owner to make some decisions about the relative importance of the unfinished stories.
David finds all of the 'partial credit' approaches unsatisfactory and recommends that team be given no credit until the original story is fully completed. He recommends that the story be re-estimated and put back in the backlog. In David's words: "This model keeps things simple and keeps teams from gaming the numbers."
How does your team handle partially done stories? Post a comment and share what is working, and what isn't.
A second possibility is to split the story into smaller stories and take credit for the ones that can be considered done.
Why wouldn't you have split the story in the first place? You shouldn't just stop splitting when you think you have something that will fit into a single Sprint!
This is also something that is dependent on the length of a Sprint. The longer the Sprint, the higher the likelihood that something will not be completed, although that may sound counterintuitive. From what I've experienced, people are reasonably good at estimating smaller pieces of work, i.e. on the order of a few days to a week. The larger the work item, the lower the accuracy in the estimate. So, split the Stories until you can't split anymore without delivering value.
As for dealing with incomplete Stories, as always it depends. I do tell teams that they can't use the incomplete work against the previous Sprint's velocity, but they can revise the Story's estimate for the next Sprint if it makes sense to do so.
totally agree... no credit, no split
Kevin E. Schlabach
You wouldn't go into a restaurant and pay for a burger, and then accept the bun now and the burger and tomato in 10 minutes.
I discussed the >appropriate time to split a story on my blog.
Product owner decides
Split the story
How I have handled unfinished stories
1. Which stories are unfinished (story complexity, story priority, impact on iteration, impact on release, impact on other stories)?
2. Where is the team in the release lifecycle (beginning, middle, end)?
3. Nature of the commercial contract with the client.
4. Client's willingness to engage in a "negotiation".
Various approaches I have tried and the lessons learned are:
<strong>Option 1</strong>: <em>Split the story into smaller stories and claim points for finished pieces</em>
My first question would be, why did the team not come up with smaller stories upfront? It is important to work with the team and understand if the team can do a better job of coming up with smaller stories upfront. With a team that is completely new to agile and has previously never been exposed to creating stories from requirements, a tendency to split stories towards the planned end of an iteration may be understandable but over a period of time, such occurrences should not happen at all.
<strong>Option 2</strong>: <em>Push an unfinished story into the next iteration (sprint)</em>
Most clients aren't happy about this since the instictive reaction it induces from a client is that the iteration milestone is being pushed out and will in turn push out the release milestone. Clients have usually made date and budget related commitments within their own organizations so obviously they won't like to communicate a delay within their organization. As a Project Manager, I always analyze the impact of changing iteration dates upon the release timelines before suggesting to a client that we push a story into the next iteration. We put some buffer into our estimates at the beginning so until the buffer gets used up fully, this approach usually works.
<strong>Option 3</strong>: <em>Extend the iteration until the story is finished. </em>
This is a slight variation on option 2 and some clients (usually those who are text-book agile fanatics) actually agree to this. The rationale behind using this option is to avoid calling an iteration as complete until every planned story is really complete. The challenges with this approach and the mitigation are similar to those for option 2.
<strong>Option 4</strong>: <em>Work extra hours to complete stories</em>
Sometimes we have to resort to this option, especially when the end of the release is near or when the team has ended up using all the buffer and we have no commercial coverage to minimize impact of a delay. I have seen teams that first adopt agile resort to this option by default. If however, teams do proper root-cause analysis to understand reasons for stories remaining unfinished, they can start using more and more of options 1, 2 and 3.
<strong>Option 5</strong>: <em>From the beginning keep buffer in story estimates</em>
Using theory of constraints for estimating stories, buffers can be introduced for stories that may be risky and for which accurate estimates cannot be provided upfront.
<strong>Option 6</strong>: <em>Introduce spike solutions before taking up technically risky stories</em>
Many times my teams have slipped on delivering a story because they hit a technical problem midway through implementing the story. In most cases, this has been because the team did not really analyze a story thoroughly at the beginning of the iteration and therefore failed to anticipate areas which may require further exploration. When starting an iteration I put special emphasis on uncovering potential pitfalls and problem areas. Then if required, we create spike stories for the current iteration and push out actual functional stories into future iterations.
In all cases except option 4, the client or the Product Owner is the final authority for approving the option to be exercised (may be obvious but stating anyway).
Re: How I have handled unfinished stories
The estimation of how many story points to attributes to an incomplete story can be much harder. Answering this requires first defining what a velocity (in story points) measures, and what's the goal behind it.
I tend to have Story points measuring team production rate which mean how much (in size) can the team achieve in a Sprint. This is not a must but only a definition: You can define your own. This isn't the same as estimating how much feature have been added, because I exclude identified stories and changes found during the review. For that definition, an incomplete story having achieved 95% of the detail estimate, could get some story points but I'd rather give only a few.
The final goal is having an idea of how much can the team achieve (excluding again possible mis-communication with the P.O. and changes of mood or whatever changes the P.O. regularly has on the product backlog). By separating the varying elements (Product Backlog changes by the P.O., and the team velocity) I suppose the release estimations is more accurate.