How to Handle Unfinished Stories?

The biggest problem we have is not having sufficient 'done' criteria. I like the approach of taking an unfinished story and moving it to the next sprint. If it's not done according to your definition, the velocity is zero for that story in the current sprint.

A second possibility is to split the story into smaller stories and take credit for the ones that can be considered done.

Agile is about delivering value... this can't be obtained if the customer/user can't use the output of the story.



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.

In the review we let the product owner decide if the story is fully delivered, delivered with some work to be done or not delivered. Fully delivered or delivered with some work to be done gives all story points. If the story is not delivered no points are given. If the story is not fully delivered we write new stories that describe what needs to be done from the point where we are now.

What we do, is that during planing, the team splits each story into smaller tasks and assigns story points to each task. The tasks are usually 0,5 to 3 story points long and they represent a single piece of work (like creating one JSP). That way we always know how much of a story is left and we can include it in the planing of next sprint. If there was some work done on a task we either try to estimate how much work is left (in such short tasks it is very accurate) and include in the next sprint only the work left or we move the whole task in next sprint. This is what bests suits our team and fits best in our environment.

I don't think there is an easy answer to the problem at hand. In my experience, the most optimum solution depends on the following:





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).

Even a 99% complete story which is not accepted or changed by the P.O. should not be accepted as complete. That defines what a complete story is: Something giving value to the product and which is shippable.

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.