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
  • 414

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
  • 85,641
  • 18
  • 207
  • 307
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,048