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?
2
-
2Possible duplicate already answered by pm.stackexchange.com/a/18228/4271, pm.stackexchange.com/a/8440/4271, or pm.stackexchange.com/a/25867/4271.– Todd A. Jacobs ♦Commented Jan 7, 2020 at 13:59
-
1Hi Adrian, I would call it normal business by normal means. If at least 50% of your sprints don't 'fail' then your organization is almost certainly deceiving itself in some way. 'Fail' is an ugly word, 'study and learn' is one better, and more accurate, way to say it.– Jeremy AndersonCommented Jan 9, 2020 at 2:16
Add a comment
|
6 Answers
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.
answered Jan 7, 2020 at 9:20
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.
-
Sprints either result in a potentially releasable increment, or not. Sprints either meet and exceed the sprint goal, or not.– pauljCommented Jan 7, 2020 at 18:51
-
1@paulj for well formed sprint goals, yes. I don’t see not meeting those goals as a failure. It’s learning, which As a methodology for delivering software Scrum excels at a framework for learning. Commented Jan 7, 2020 at 19:03
-
1Your post fills me with hope, George. I wept a little, thank you. Commented Jan 9, 2020 at 2:18
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.
For my 2 pence worth:
Lets not get confused between a sprint that has "Failed" and a sprint that is a "Failure". IMHO. A sprint that fails is a sprint that does not meet its target (ie: deliver all of the points that were assigned to it). That is NOT a failure! That is an opportunity to identify practices by the team that can be (and must be) addressed. It is something that must be reviewed during the retrospective, identifying what the cause was, what the remedy could be, and a clear plan of action to implement that remedy.
A failure on the other hand can be boiled down to one of two things. Firstly, a sprint delivers nothing. Zero points. Unless all of the developers and / or testers go on strike, or some disaster occurs and no one can do any work, this is impossible. No matter how little, something is delivered.
Secondly, The sprint goal is missed. In my experience as a scrum master, this happens through interference. If story refinement is done correctly, each story that is promoted to the sprint and its acceptance criteria must adhere to that goal otherwise, why include the story. Assuming stories are not added mid print, if refinement is done correctly and the sprint goal is still missed then someone has messed around with the stories after they were promoted to the sprint.
As with a failed sprint, a sprint that is a failure must have the root cause of that failure analysed during the retrospective and dealt with appropriately.
