13

I am part of a development team that is relatively new to Scrum, suppose that at the end of the sprint a few large stories are either in progress or were not accepted by the PO.

Firstly, what happens with those user stories? Do you just carry them over into the next sprint?

If so, should they be re-estimated? In my view the work remaining on these user stories can be minimal or a lot? If not, why not?

EDIT: In my specific case, the stories were not completed because of an impediment that was a few days long, not because of user story underestimation. For those of you that it may help, we are using VersionOne

Improve this question
3
  • I work with an XP process, and have wondered what is the best way to deal with this sort of situation
    – chrisbunney
    Jan 3, 2012 at 13:05
  • 1
    The failure to identify an impediment as a possible risk and determine the risk exposure RE (impact * probability) indicates a problem with estimation. A user story with a high RE needs to have a larger buffer of cost and time associated with it to address those risks, should they develop into problems.
    – Thomas Owens ♦
    Jan 3, 2012 at 13:41
  • double it and add 32, just like C => F
    – Paul
    Jan 3, 2012 at 17:01

2 Answers 2

Reset to default
14

Firstly, what happens with those user stories? Do you just carry them over into the next sprint?

It depends.

The Scrum Guide states that, at the end of a Sprint, unfinished Product Backlog Items are moved back into the Product Backlog and the Product Owner ensures the correct ordering of the work. However, practically speaking, if the work remains ordered high in the Product Backlog and the work is also consistent with the Product and Sprint Goals, it would be highly likely to be selected for the next Sprint at Sprint Planning.

Since one of the purposes of agile methods like Scrum is to maximize the delivered value while reducing the time, it all comes down to how much value is added by finishing those stories.

Regardless of what happens, you still need to strive for a potentially shippable product at the end of the sprint. This might mean rolling back to ensure that the end-of-sprint product passes all tests and the completed features are fully usable by the user without any significant problems.

If so, should they be re-estimated? In my view the work remaining on these user stories can be minimal or a lot? If not, why not?

I would not reestimate because, in Scrum, a Product Backlog Item is either done (designed, developed, tested, and acceptable) or it's not done. If there's no concept of partially complete, there's no way to determine how much work is remaining on the story. You estimated the work that you thought you can do, so leave this data point in and make it a point to discuss why the estimate was off in your Sprint Retrospective and try to avoid making that mistake for future sprints.

Improve this answer
15
  • 1
    We have only experienced this once, and it wasn't to do with the estimate being wrong, we had an impediment of sorts that resulted in the work being done, but not tested.
    – ediblecode
    Jan 3, 2012 at 13:20
  • @user1016253 That means your estimate had a problem. Estimates should include risk exposure (impact * probability = exposure, where exposure has an impact on cost, time, and quality). Because there was an impediment that happened, but the estimate didn't account for it (or didn't account for enough of it), something was either overlooked or mis-assessed (the impact or probability was too low, meaning the exposure was too low, meaning there wasn't enough resources allocated to identifying and correcting the problem when it happened).
    – Thomas Owens ♦
    Jan 3, 2012 at 13:29
  • @user1016253 And if you are having trouble estimating and seeing risks and potential roadblocks, perhaps a good idea would be to decompose the story, either into multiple stories that each go into the backlog or sub-stories for use only by the development team to understand the work that needs to be done. It's often easier to estimate and perform risk analysis on a smaller unit of work.
    – Thomas Owens ♦
    Jan 3, 2012 at 13:38
  • 1
    @Thomas Owens: That doesn't seem to be a useful way to manage risk to me. In particular, a low-probability event that isn't catastrophic is low exposure, and therefore even a well-managed project can be thrown somewhat off schedule on occasion. If you never take a risk, you'll accomplish very little. Of course the estimate tracking does need to avoid accepting such excuses, or you wind up making estimates that are only as valid as the investments that led to the recent mortgage crash, and for the same reasons
    – David Thornley
    Jan 3, 2012 at 16:05
  • @DavidThornley It's not a way to manage risk at all, but a starting point for a risk management plan that would also include detection and mitigation strategies. It's a technique used to ensure that you have sufficient money and time in your plan should risks develop into problems. It's advocated by Steve McConnell in Software Estimation and Karl Wiegers in this paper. It's important to realize that it's not a per-task buffer, but a project (or iteration) buffer should various risks materialize.
    – Thomas Owens ♦
    Jan 3, 2012 at 16:24
1

Typically, it is up to the elected Scrum master to decide what is to become of the tasks that have overrun a sprint, obviously after consulting the rest of the team and the project sponsor/product owner. At the end of a sprint, it's a time to review what the priorities are. It's possible the story in question is of a lesser priority than a new/existing story and it is to be put back on the tracker as 'ongoing' or whatever label your tracker uses, indicating that this story is to be followed up at another point in time. Alternatively the story may be descoped completely. You haven't mentioned what tracker you are using, but most of the ones I've seen allow you to set a story to 'descoped' if it's no longer part of the project.

Secondly, since your team is new to Scrum, this is all part of the learning process. You've now recognised that some stories are too large, so your team will take more time to break the stories down. It's typically the onus of the scrum master to make sure this happens. The Scrum master will also need to consult the project sponsor/product owner with incomplete stories to try and break them down further or get the final say on descoping them entirely.

In my team, a new Scrum master is elected every 2 weeks (sprint), so everyone gets a shot at managing tasks, organising Scrum meetings and ensuring everyone submits progress reports. I'm hoping that's the case in your own team, it's certainly a good experience.

Improve this answer
4
  • 4
    Nitpick: The decision what to do with the incomplete story is a question of priorisation. Thus I believe the product owner should decide this, not the Scrum master.
    – sleske
    Jan 3, 2012 at 13:22
  • @sleske - Agreed. I should have made that clearer in my answer. Originally I said the scrum master would consult the team, but I should have included project sponser/owner, which I've corrected. Thanks for the head's up though.
    – Desolate Planet
    Jan 3, 2012 at 16:03
  • If incomplete stories are still incomplete at the end of a sprint, you can't really break them down at that point because that is likely to completely subvert the Definition of Done - "So you're saying that part of the story is Done? But it hasn't been code reviewed yet!" This is why epics-as-single-stories are horrible and should never be allowed into sprints.
    – Robin Green
    Aug 12, 2015 at 19:31
  • 1
    @RobinGreen I agree with your take on epics and I'm not a fan of them. One of the key things (something a lot of people I've worked with overlook) is the value of retrospectives. We recently started using JIRA's Agile board and I frequently show the team the burn down chart of the teams performance. Incomplete stories are discussed if and when they happen and immediately put back into the backlog. In the retrospective, we look at why the story was incomplete. Lack of resources? Lack of knowledge? or perhaps a loose combination of the two.
    – Desolate Planet
    Aug 12, 2015 at 20:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.