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

ediblecode
  • 404
  • 3
  • 14
  • I work with an XP process, and have wondered what is the best way to deal with this sort of situation – chrisbunney Jan 03 '12 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 03 '12 at 13:41
  • double it and add 32, just like C => F – Paul Jan 03 '12 at 17:01

2 Answers2

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.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • 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 03 '12 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 03 '12 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 03 '12 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 03 '12 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](http://www.compaid.com/caiinternet/ezine/Wiegers-Rainy.pdf). 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 03 '12 at 16:24
  • Risks that impact the amount of effort involved in a task should be included in an estimate, but the OP describes a risk that effects the calendar time of a task but not the man*hours of a task. Adding risks like these to an estimate would inflate a teams velocity, when it wasn't doing any work due to the risk in the first place. – Chris Pitman Jan 03 '12 at 18:13
  • @Chris If the risk doesn't materialize, you have extra time. In a sequential process, you progress to the next phase early. In an iterative process, you can take the time to pull the next highest priority story into the backlog, or perform refactoring, or write additional tests, or work on things that exist outside of the project (training, meetings, other projects). There is no inflation of velocity, since the time is filled - Parkinson's Law applies. – Thomas Owens Jan 03 '12 at 18:50
  • I agree that the time can be filled. LEts say you have two tasks, A and B, both which take 4 hours of actual effort. Lets say A also has significant risk of being held up by outside factors (lets say by 4 hours). We start A, switch to and complete B, then go back to and compelte A. The team has only completed 8 hours of work, but if we added this risk to A's estimate (making it 8 hours) the velocity would credit 12 hours of work. Obviously this is a very artifical example. Is there something I am missing? – Chris Pitman Jan 03 '12 at 19:30
  • @Chris The buffer would only be a fraction of the risk exposure. I believe 20% is a typical number, so if something happening had a impact of 4 schedule hours and a chance of 50%, the risk exposure would be 2 hours and the buffer would be 20% of 2 hours, which I would round to 0.5 hours. The largest buffer for a 4 hour task would be (with rounding) 1 hour. This is because not all risks will happen and might not be as severe as you expect, so you don't need to buffer everything. – Thomas Owens Jan 03 '12 at 19:38
  • @Chris As far as velocity, I'd bring in fewer hours of work (or story points, if that's how you calculate). I'd assess my risks in terms of the same units as a story and make sure that actual story points + buffer story points = velocity from the previous iteration. In a low-risk iteration, you bring it a lot more actionable work. In a high risk iteration, you bring in a smaller amount of actionable work, but are able to pull down from the backlog if risks don't materialize. In the end, velocity averages out throughout the project. – Thomas Owens Jan 03 '12 at 19:40
  • @Thomas Owens: Thank you for the link; very interesting. What I'm arguing is that any reasonable estimation method can only get the probability of exceeding the estimate so low, and so there is a chance, however small, that the deadline will be missed. Obviously this should be discussed in the post-mortem, and taken into account for later estimates, but I just don't see it as necessarily an estimation failure. – David Thornley Jan 03 '12 at 23:09
  • @DavidThornley It depends on how you define "failure". Perhaps failure is even the wrong word. The ultimate goal is to get your estimate as close as possible to actuality and do that consistently. Every estimate needs a range or confidence interval, and when the actual value doesn't fall within or close to that range, it needs to be evaluated somehow. In the end, you need to define what's acceptable for your project and improve estimation techniques to the acceptable level. – Thomas Owens Jan 03 '12 at 23:13
  • Hi Thomas...Can you please share what to do in situations as mentioned here - http://www.unknownerror.org/opensource/bendc/sprint/q/stackoverflow/626892/work-out-sprint-capacity-when-carrying-over-story-points-in-scrum – Dinesh Apr 07 '16 at 13:36
  • @Dinesh If you have a new question, you should ask it. However, the answer is C. You shouldn't be using average velocity, but the previous sprint's velocity. That is, the number of story points brought into the sprint being planned should be equal to the number of story points completed in the previous iteration (or as close as possible - within a couple of points, perhaps). Be sure to account for a change in capacity, though (team members leaving, new team members, vacations and holidays, other events...). – Thomas Owens Apr 07 '16 at 13:40
  • @ThomasOwens Sorry for not posting as a question! I was in a time crunch...Appreciate your very quick response :) – Dinesh Apr 07 '16 at 14:47
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.

Desolate Planet
  • 6,038
  • 3
  • 29
  • 38
  • 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 03 '12 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 03 '12 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 '15 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 '15 at 20:43