Being Cellfish

Stuff I wished I've found in some blog (and sometimes did)

Definition of a failed sprint

Change of Address
This blog has moved to blog.cellfish.se.

Definition of a failed sprint

  • Comments 2

Recently there was a discussion on an internal mailing list about when a sprint was was considered a failure. Specifically the question was asked if seven out of nine user stories completed meant that it was a failure. Naturally that should be considered a failure! NOT! As far as I'm concerned there is no such thing as failure in Scrum. Scrum is not a method that can be used to measure success versus failure. Scrum is a method that helps you understand what your real problems are. As long as you learn something and continue to improve you cannot fail. If you ignore all signals and refuse to learn from your mistakes (and successes) then you fail.

One thing that probably is the source of confusion is the sprint reset. That is before the end of a sprint the team (or product owner) realizes that the current plan is just wrong and that the best thing to do is to stop the running sprint and plan a new sprint instead. While this should be considered an exceptional case and if it happens a lot you need to understand why. But it should not be considered a failure, it's a great opportunity to learn.

  • When I started scrum, our CSM instructor provided us a technical definition of failed sprint:  A sprint fails when a story started in the sprint is not done by the end of the sprint.  While this can happen for many reasons, some outside the team's control, the definition makes sense to me.  Agile Scrum's goal is to create completed, deliverable value.  If a scrum team starts nine stories and gets them to 99% done, at the end of the sprint they have no deliverable value.  On the other hand, if the team starts one story, presumably the highest value story from the top of the backlog, focuses on it, gets it to done, and then ends the sprint by expiration or premature termination, the team created positive, deliverable value for the product owner and other stakeholders.  If teams prioritize quality over quantity and done over started, they will tend to control work towards creating and completing real, deliverable value.

  • It is an interesting view that there is a failure if a story was started but not completed but not a failure if the story wasn't even started. If you insist on using the word failure I would choose that definition. But I think the term "failure" should not be used here. The only thing that happened was that you did not finish all your planned work. That is not a failure but an opportunity to learn and not do it again.

Page 1 of 1 (2 items)