A sprint has just ended. All stories, but one were done by the software engineers. Should the sprint be labeled as 'failed' because of the story that was not completed? What exactly is a failed sprint?
According to Mike Cohn
It’s quite common for a team to have a bit of unfinished work at the end of an agile sprint or iteration. Ideally, a team would finish every item on its sprint backlog every sprint. But, for a variety of reasons, that isn’t always the case.
Accordingly to Scrum.org:
- The Scrum Goal is the creation of productive and creative products rather than projects.
- Each Sprint is an experiment. Its results should be inspected and correspondingly adapted.
- If it is impossible to Inspect the results of the Sprint (experiment) and to Adapt, it is considered a failure.
From this, we learn the sprint shouldn't be labeled as failure just because one User Story wasn't finished (that User Story should go into product backlog and not directly into the next sprint though). When can we then say the sprint was a failure? If we can't inspect the results of the Sprint and adapt.
Example of a failed Sprint:
The team managed to complete a big number [sic] of functionality and brought to the Sprint Review exactly what it forecasted [sic] ("thanks" to some overtime and lowering quality). But nobody is present at the Sprint Review except the Product Owner. The Development Team never sees the end-users, and other stakeholders are always too busy to visit the Review. There is no feedback on the Increment. Then we skip the Retrospective because we have a lot of work to do. We start the next "successful" Sprint.
I am personally adverse to the idea of ever saying a sprint 'failed'.
Scrum uses the term 'inspect' 27 times, and 'adapt' 16 times over the course of the guide.
Scrum also has no notion of 'failure', and the only reference to failure in Scrum is listed here:
Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.
Scrum's purpose isn't to give you confidence that you will deliver every single story you create, in the sprint they were assigned to. That's a management artifact that we assign to scrum because we're human and we like to believe we're in control.
In fact, in the agile manifesto, they say something very key to determining 'success' or 'failure':
We are uncovering better ways of developing software by doing it and helping others do it
That doesn't sound like the manifesto of someone that has all the answers. We are uncovering better ways of developing software -- notice the present tense. Software development is an emerging field where hidden constraints of people and machines are uncovered every day. It's going to happen to you and your team, and it happening -- and thus putting a story in jeopardy of being delivered -- isn't a failure, it's natural.
Scrum's purpose is to give you short iterations to try to deliver working software in that will be used by the customer, and then adapt to changing circumstances as they come up. "Failure" in the eyes of scrum would be to not change when the circumstances change, to not 'inspect and adapt', as it were.
In fact, Scrum doesn't use the term 'commitment' any longer in the Scrum guide -- they've changed it to forecast, for the exact reason I list above. We may get upset at the weatherperson when they get the forecast wrong, but we still have to have our umbrellas ready if they are wrong.
That's Scrum. Having your umbrella ready -- not firing the weatherperson because they got the forecast wrong.
If your team has inspected and adapted; if they've responded to changing circumstances, if they have adapted -- then they haven't failed. They've done precisely what agile methodologies and what Scrum dictates.
During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
So basically, in each Sprint it's not enough to keep yourself busy with work, or to make sure all the stories you took in the Sprint get done by the end. You also want to achieve something that adds value to the product. So you set yourself a Goal. If you reach that Goal, your sprint is a success, if you don't, you can say you failed the Sprint.
So defining what a successful or failed Sprint means depends on the Goal, not the stories you work on. The goal of the sprint is not to finish all stories in the sprint, the goal is something that adds value. For example, the work you do during a Sprint doesn't always relate to the goal you decided upon. Say your goal is to "Add the shopping cart functionality" and you have stories for that. But you might also work on some bugs which aren't related to the goal. If you fail to fix all the bugs but build the shopping cart functionality then your sprint is a success. If you fix all the bugs but fail to build the shopping cart functionality, then you failed to reach your goal.
Sometimes you can fail your goal for other reasons. Maybe you were too ambitious, maybe you vaguely defined a goal and by the end you get a better understanding and realize you wanted something else, maybe you sacrificed some quality to reach it, sometimes s#it just happens, etc. If you miss your goal in one sprint, it's better to focus on ways to improve your further sprints than dwelling to much on the fact that you "failed" a sprint.
A failed sprint means you did not reach the sprint goal.
That can mean all stories but one were completed, but that one was critical to reach the goal.
Only you can know whether this is the case here.
Keep in mind that the stories pulled into the sprint are a forecast of what the team should be able to do. Saying "all stories must be done" as some inexperienced people do, is not very productive, because that means you have no focus in your sprint, with every story being of equal importance. In addition you set yourself up for failure, because if you can do X stories on average, you are bound to miss that forecast roughly every other sprint, that is the nature of "average" or forecast.
Backlog and 'Fail-fast' are at the very foundation of agile development.
In a way, 'Failure in a sprint' is actually a desirable quality.
Failed sprint, according to me, is a well-executed sprint. Failure facilitates continuous improvement.
100% success of sprint happens in 2 cases:
- Team is complacent and is not pursuing ambitious goals.
- Organization is adhering to strict process that does not allow team to operate efficiently / creatively.
Major failure of sprint happens when the organization has a governance model / an unavoidable process that interferes with development activities.
Small failures do happen (supposed to happen) in a well-executed sprint.