Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

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

2 Answers 2

up vote 9 down vote accepted

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

It depends. If no other story has a higher priority, then, yes, they are moved into the next sprint. If other stories have a higher priority, then they might be moved back into the product backlog if there is not enough room in the sprint to accomodate them. This all happens in the sprint planning, based on the priorities assigned to each story by your Product Owner. 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, you estimate a story when you accept it, begin work, and don't have a concept of partially complete. A story is either 100% complete, tested, and accepted (done) or it's not done. If there's no concept of partially complete, there's no way for you to determine how much work is remaining on the story. It appears that I'm not alone in this thought, either. 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 postmortem and try to avoid making that mistake for future sprints.

share|improve this answer
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. –  danRhul Jan 3 '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 3 '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 3 '12 at 13:38
    
thank you for all your advice. You've been a great help –  danRhul Jan 3 '12 at 13:40
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 '12 at 16:05

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.

share|improve this answer
3  
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 '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 3 '12 at 16:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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