Posted by: rusteddev | February 12, 2011

Scrum Question : Is it bad to fail a sprint ?

In my first agile days, I asked myself these questions . How bad it is to fail the sprint? What happens then ? How should the team member, Scrum Master or Product Owner act when it happens  ?

After month of practicing, I’ve come to this : I don’t think failing to deliver one, two or even all user stories of a sprint to be a bad thing. It’s a great opportunity actually. OK ….but let me be clear: Failing to deliver the software increment the team agreed at sprint planning is something to take into serious consideration. As an agile promise, the product owner wants to see constant delivery of features. By repeatedly not delivering what we agreed might lead to disappointment. Repeated disappointment can lead the PO to either change the team or stop the project. But nevertheless, this is why you should be “happy” (or I mean not so unhappy) to fail some user stories :

It’s the same for every beginning SCRUM team. If you fail (especially in early stages), it means you are just doing it right. Most of the teams fail their first or second sprint. And no team that I know did succeed every acceptance test in a product backlog. On the other side it is a shame not “playing” seriously and doing double estimates so that the team delivers whatever happens.

SCRUM is an empirical method ! It’s based on testing and adapting. Learning and constant improvement are part of the deal. Failing is the first and necessary step toward improvement. If you analyze what went wrong inside the team, define immediate counter actions and act accordingly in next sprints you will certainly avoid this failure int the future.
To have a less failure impact I suggest you should reduce the length of the sprint. it’s not such a big deal to fail in a 3 days sprint than a 3 weeks one. This way you also iterate more often, get more feedback and constantly improve the way you are doing things.

Failing the sprint make problems visible ! Failing might be a way to catch attention on something, expecting change.

In our team, we where a few weeks ago in the situation to “almost” finish the sprint. It was a tough sprint, we worked hard and did home working…. By “almost” finish I mean we were close from a customer point of view, and we could have ended up on time with all acceptance test passed. But we could never be “done” according our definition of done. The team agreed not to submit the user story on sprint demo. More than our will to be honest with ourselves and the PO, we did also this to catch up more attention on us.

Until then the team was doing pretty well and did not fail a single user story. From the outside, things were going well. Management was not responding to our request of adding some technical expertise. By failing to deliver expected result, we immediately catched up attention of PO and Management of the company. They were aware and were looking for solutions.

We did a proper retrospective just after and suggested ways of improvement. Among other things we should also need technical support especially in Tests Driven Development as we failed but still wanted to deliver high quality code.

A few weeks ago 2 experienced dev joined the team. If we decided to go on, and submit the user story to PO acceptance tests, maybe they would have passed. But we would have cheated PO, delivered crap, continued working extra hours, not obtained reinforcement and have 100% chances to go on like this as everything would have been OK from an outside point of view…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: