Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Don’t Start What Cannot Be Done

Don’t Start What Cannot Be Done

Leia em Português

This item in japanese


Many Agile teams face a dilemma when picking up a new story towards the end of a Sprint. There is some time left but this time may not be enough to get a story done-done. An interesting discussion on the Scrum Development group tries to address this concern and find some answers.

According to Alan Shalloway, who started the discussion,

What'll happen if you half code something? You now have bleed-over (incomplete stories into the next sprint). If you already have bleed-over, adding to it is not a good idea and I'd rather the dev help close other stories that would otherwise bleed over into the next sprint. Work in process has a negative effect. We want to lower it and certainly not add to it.

The idea seems to be that instead of starting on a new story, more focus should be on completing the stories which are on verge of completion and would add business value.

Rob Park suggested that some unfinished stories rolling over from one sprint to the next might be a healthy sign. It would suggest that the team was working with consistent velocity. Zero work in progress could be an indication that the team is under-committing and has some amount of idle time towards the end of the sprint.

Jose M Beas added that if there is a story that can only be partially done during a sprint then it might be a good idea to break the story into smaller stories. This way, instead of keeping a large unfinished story a team can have smaller finished stories.  A related post on InfoQ also suggested splitting the story into smaller stories as a viable option for treating unfinished stories.

Ron Jeffries added that, though he agreed that carrying over unfinished work might not be very helpful, however starting a story and carrying it to the next sprint is not very different from carrying an unfinished story over a weekend during the sprint. According to him, if there is not enough useful stuff that can be done towards the end of a sprint then starting on a new story might not be a bad idea.

Philip Cave echoed his thoughts on similar lines, according to him

Minimize WIP [Work in Progress], but we must have some WIP … any process must be seeded with just the right amount otherwise your "production line" comes to a standstill – AKA Standard Work In Process (SWIP).
One purpose for the time boxes in Agile is to create SWIP (to help manage our flow), another is to create short feedback loops with the customer (mistake proofing) … thus allowing us to define just the right amount of work and deliver value just in time.

Most Agilists on the discussion forum agreed that unfinished stories is a common reality than a rare event. During the sprint planning for the next sprint the story points for an unfinished story should be adjusted according to the amount of work left.

So what can be done towards the end of the Sprint instead of picking up a new story?

Alan suggested,

Using the time to write more test specs for upcoming stories, doing a little analysis, or cleaning up something that you've been meaning to do would be better.

Philip Cave suggested that the teams should ask relevant questions to themselves to manage their Standard work in progress, according to him

If we get close to the end of the cycle, and the story points for remaining stories tell us we do not have enough time to complete the story for this cycle that is when we ask … do we pull in another smaller story … do we schedule the review with the customer now … or do we pull in an "analysis" story preparing for the next cycle of work … or do we do something else …

Thus, the common message is that before starting a new story the team should evaluate various options which might add value. If the maximum value can be derived by starting a new story and carrying it over to the next sprint then the team should not be reluctant to take this path.

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

  • Is this a scrum problem?

    by Kevin E. Schlabach,

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

    Iteration boundaries are a point in time to measure velocity. Just like miles/kilometers per hour, you need a time unit of measure to measure velocity.

    When teams run out of work a half day before the end of the sprint, they should not sit and do nothing. It means that they should pick up the next story of priority, and it would benefit them to ask the product owner which one. Consider it a head start on the next sprint.

    There are a lot of anti-patterns to be hidden in this problem, but I shake my head at this discussion at the philosophical level because sprint boundaries on mature teams shouldn't be this big of an event.

    Kevin E. Schlabach

  • Optional work

    by Farzad Kohantorabi,

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

    I usually plan optional work during sprint planing, and those optional works are usually more of clean up tasks or small refactorings. Sometimes the optional work is code/technology investigation for work items that should go in future sprints. This has proven very useful with my team. However, not all these optional works are delivered to our QA at the end of sprint because they are always busy. In this case, we branch the code but still continue with the development.

  • This is a problem?

    by Bruce Rennie,

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

    May circumstances strike me with this problem every sprint.

    And, call me crazy, but if a team ran out of work a half day before the end of a sprint, I might be tempted to tell them all to go home. The first time it happened, anyway. :)

  • Be true to Scrum - Let the team decide!

    by Assaf Stone,

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

    If you're at the end of a sprint/iteration, without enough time to complete the next, user-story, i.e. the remaining one of the highest priority, let the team - yeah, that self-empowered one, decide what to do with the remaining time.
    There won't be one size to fit all. If you've got 4 days, and all the next story is 5 points or more, likely the team may decide to pull a smaller, slightly less important one. Or break the important one, or work on a technical debt, or anything. Try it, and retrospect it.

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

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