Sprint Goal and Failure of a Sprint

Question

My organisation is pushing for strictness on what they consider a Sprint Failure or not.

They have decided that if there are any User Stories not fully completed (as per the DoD) at the end of the Sprint, the Sprint has failed. This also includes Stories that have been removed from the Sprint (either because the Dev Team realised it could no longer complete the work, or because the PO has deemed the Story as redundant or lower priority).

I understand the concept and the objective of this (complete all planned work in a given Sprint seems sensible) but there is no focus on the Sprint Goal. To me, the objective of each Sprint is to achieve the Sprint Goal. If this means a Story has to be removed (without it affecting the Sprint Goal), then it's not necessarily a Sprint failure. The team can still learn from this in the next Sprint.

If a User Story was not completed in full but the Sprint Goal was still achieved because the unfinished Story was not that vital to the Goal, is this really justification for a failed Sprint?

As a Scrum Master, I have a hard time with this 'rule' but I'm not entirely sure how to back my opinion up. Any thoughts?

Answer 1

TL;DR

They have decided that if there are any User Stories not fully completed (as per the DoD) at the end of the Sprint, the Sprint has failed.

This is not only incorrect, it's an abuse of the Scrum framework and a thorough misunderstanding of how work is selected for inclusion into a Sprint.

The purpose of a Sprint is not to complete user stories. That's simply a means to an end. Rather, the purpose of a Sprint is to provide a time-box to work on Product Backlog items that collectively deliver the value defined by an overarching Sprint Goal.

Sprint Failure Conditions

While not addressed specifically within The Scrum Guide, a Sprint really has only three failure conditions:

1. The Sprint Goal has not been met.
2. The delivered Increment is not in usable condition.
3. The Increment does not meet the "Definition of Done."

That's it. Individual stories can be done or not-done, forecasts (estimates) can be missed, and the team may have successfully delivered the wrong MacGuffin. Such Sprints are still technically "successful" in that they delivered a potentially-releasable Increment and leveraged the framework to provide the business with process transparency and appropriate opportunities to inspect-and-adapt.

Sprint Goals and Increments

The following elements of the Scrum framework are explicitly defined in The Scrum Guide. The Sprint Goal is developed during Sprint Planning, and provides guidance throughout the Sprint. The Increment is the work completed according to the Definition of Done, and is essentially the de facto deliverable for the Sprint.

Sprint Goal

The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

Increment

At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.

Educational Opportunities

In general, your management team's approach is exhibiting a number of smells that indicate a faulty Scrum implementation. It is the Scrum Master's job to educate the entire organization, including the Scrum Team and senior management, about the way Scrum actually works.

Specifically, you should use this as an opportunity to address the following project smells implied by your original post:

1. A Sprint should have a coherent goal.

   As defined by the Scrum Guide, each Sprint should have a defined goal which causes the team to work together rather than on separate initiatives. If you don't have a coherent Sprint Goal, a coherent Increment, or a collection of Sprint Backlog Items that are interrelated, then the framework is being implemented incorrectly.

2. Work is selected by the Scrum Team, not assigned from the outside.

   The Product Owner prioritizes work on the Product Backlog, and the team negotiates with the Product Owner during Sprint Planning to select stories for the Sprint Backlog that will:

   • Fit within the time box.
   • Support the Sprint Goal.
   • Collectively deliver a vertical slice of value.

   Assigning stories to the team, selecting unrelated stories, or failing to leverage the "team" aspect of the Development Team when performing Sprint Planning are all huge red flags.

3. Forecasts are not money-back guarantees.

   Sprint Planning is a short-term planning exercise that estimates both level-of-effort and team capacity to arrive at a reasonable forecast of the work that can be completed within a given time box (the Sprint) with the resources and knowledge currently available. Forecasts can be missed for a wide variety of reasons; it is not inherently a failure of either the framework or the team's work during the iteration. Instead, a missed forecast is an opportunity to:

   - Learn more about the problem domain.
   - Inspect-and-adapt the framework or development process.
   - Improve estimating techniques.
   

4. It is more effective to iterate rather than to affix blame.

   If your organization is trying to "hold people accountable" for forecasts, they have misunderstood the difference between an estimate and a guarantee. Educate them about how iterative development and iterative process improvement actually work, and explain how the Scrum framework provides them with the tools they need to effectively manage emergent designs and processes.

Answer 2

A sprint should be considered as a time-box in which to limit the scope of work that can be (hopefully) successfully completed. A sprint doesn't succeed or fail, it just ends.

The real measure of success or failure (if you want to re-direct your organization's attention) is how a set of user stories meets the user's stated requirements. Most of the time, there are several stories that can "attach" to a single user requirement. These can be rolled up into an Epic and directly associated with the user requirement. (This is your basis for the RVTM by the way.)

The "Goals" exist for a project. Those goals include user requirements. The user requirements are separated into technical/usability/functional and into budget/schedule/resource related areas. The sprints are a useful building block to consider how the overall engineering and tasks are executed to meet your customer's project requirements.

(I have decades of DoD contracting experience, and have run into this point of view before. All parties needs to have a clear understanding of where to appropriately apply the terminology and project-level requirements.)

Answer 3

There is no such thing as a 'failed sprint'.

You bring work in according to your velocity and attempt to complete it within the sprint. If you don't complete all the work you bring in then your velocity is reduced and you bring less in to future sprints.

There is inherent uncertainty in any sprint due to the following reasons:

• There is always some technical uncertainty
• There is always some requirements risk
• Team members may unexpectedly have less time than was planned for (due to illness or some other distractions within the organisation
• Estimates are not perfect

As such there is never a guarantee that you will complete all the planned work.

To only judge a sprint as a success when all stories are completed is going against the spirit of Scrum and Agile. It is also a risky approach as it could potentially result in:

• Team's cutting corners to avoid a 'failed sprint'
• A culture of fear of failure
• Reduced morale

Answer 4

Sprint Goal is something what should help the team to focus and understand purpose of the sprint better, not to determine team's failure. If your organization uses this for performance evaluation they use it wrong and it can cause more harm than good.

What they should follow is burn-down chart and velocity, not FAIL/PASS flag.

Sprint goal is really something what should help the team and PO keep on track (Do I contribute to the Sprint Goal?), to make contribution and decision making (When the sprint should be canceled?)

Also, when you search a little about sprint goal, it is obvious that goals like: "To complete all the 5 items we pulled to the sprint" are considered to be poor sprint goals which do not help or serve any purpose.

If people judge sprint only considering finished items they are missing a lot from project complexity. That is also the reason, why they should not do it and rather focus on measures typical for scrum.

As other people write here, there is nothing like failed sprint. There is sprint in which something can be done better, for sure. However, to judge what went wrong and what can be improved is usually done during the Retrospection where PO+Team+SM discuss this. The organization is here to support, not to pass judgments.

Unfortunately, this is not untypical as in some cases management ignores the complexity and tries to fit the old thinking on the new framework. If I would be in your place I would:

1. Diminish any impact on team's morale as much as possible. Explain them what Sprint Goal means, that they set the goal, not organization and that PASS/FAIL flag is not important at all.
2. Try to emphasize other indicatives for performance evaluation like burn down and velocity to the organization. Pay attention when sprint FAIL/PASS is mentioned and if that is really important and why.
3. Try to point out that sprint planning is for forecast of the sprint, nothing more. And that there is no actual FAIL as per retrospective prime directive:
4. Try to teach organization about the quality sprint goal and its connection to sprint backlog

Be patient, some things take time to change.

Answer 5

Planning is part of the sprint. If you're removing stories then your planning was defective and the sprint could be said to have failed. If you sign up for a dozen points worth of stories, and only complete 1, but remove the rest of the stories from the sprint backlog, could you say the sprint was successful?

The failure should be recorded so that remedial action can be taken. You should not be saying everything was ok, because the team failed at estimation. Your superiors obviously think that this is worth tracking and you should pay attention to the feedback and get better at estimation.

The temptation would be to game the system though -- you could only ever commit to a single story point, then over deliver every sprint. This should be seen as a failure too.

However, there should be some margin for allowed error in the measure of velocity that leads to success/failure status. Depending on the natural variability of your measured velocity. If, say, on average you manage 20 points per sprint, but you deviate by up to 3 points, then you should only really fail if you drop below 17 points. But, again, this is open for gaming and abuse -- what is an acceptable variance level? You might average 20 pts but vary by 15! That is, the margin should be small. Perhaps 10% or less. If you're signing up for stories not points, then if you're signing up for 10 stories, then you might allow a margin of error of 1 story -- because nobody is perfect all the time. Or you might not -- every mistake or failure is a learning opportunity.

Answer 6

TBH, you should simply throw away the concept of a failed sprint. As the saying goes (and as you point out), the only failure is not using it as a chance to learn. What were the causes of not completing the items? Is the team still learning how to plan manageable amounts of work? Did "unknown unknowns" emerge? Did something external block people? And in the end, did it actually harm the delivery of value towards the goal(s)? Talking about these, coming up with improvements, and helping the team along the road of self-learning to be more responsive is far more valuable than deciding whether or not it was a failure or "success".

Answer 7

Planning is part of the sprint. If you're removing stories then your planning was defective and the sprint could be said to have failed. If you sign up for a dozen points worth of stories, and only complete 1, but remove the rest of the stories from the sprint backlog, could you say the sprint was successful?

Engineer Dollery

-

My response to this is if the Sprint Goal was achieved then yes, the Sprint can be considered successful. Not only was the Sprint Goal achieved (and there is good argument for saying it could be considered successful even if the Goal was not achieve), but the team can better plan (adapt) for the next sprint by inspecting the previous Sprint's planning mistakes. Where there is a lesson learned (or the opportunity for it), there has been success.