Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News How to Handle Unfinished Stories?

How to Handle Unfinished Stories?

This item in japanese


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.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • hmmm...

    by Jason Little,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Story Splitting

    by Dave Rooney,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

    Dave Rooney

    Mayford Technologies

  • totally agree... no credit, no split

    by Kevin E. Schlabach,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Product owner decides

    by Christian Schneider,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Split the story

    by Yasin Hamid,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • How I have handled unfinished stories

    by Manish Baxi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Re: How I have handled unfinished stories

    by Werner Beroux,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p