If your Sprint was "accidentally successful," then the Sprint is still a success. It just means that future Sprints might not succeed without process change.
Why This is a Good Question
When using an iterative, agile processes such as Scrum or Extreme
Programming, what conclusions can be drawn from successful or
This is a great question because it goes directly to the heart of what
agile practices are about, and explores the nature of the explicit and
implicit controls that underly frameworks like Scrum and XP.
Defining a Successful Sprint
A successful Sprint generally meets all of the following criteria:
- The Sprint Goal was met.
- The Sprint Backlog was completed according to the "definition of
- The Sprint Review demonstrated user-visible features that elicited
constructive feedback from stakeholders.
However, the definition of success deliberately leaves out issues of
velocity, story point estimates, internal processes, or scope changes
approved by the Product Owner the don't compromise the Sprint Goal.
If your Sprint met the goals, you should probably declare success and address any continuous improvement issues within the Sprint Retrospective. For example, if your Sprint was successful but the team's process was not reliable or repeatable within acceptable variance limits, that doesn't mean the Sprint failed--it just means the next one might not succeed without process change.
Defining a Failed Sprint
This is actually harder to define, because a Sprint can actually succeed
through failure. For example:
- An abnormal termination by the Product Owner with a return to Sprint
Planning can allow the organization to take advantage of an
- Failing early and performing a retrospective before returning to
Sprint Planning can represent a cost savings over failing to deliver,
or over delivering the wrong thing.
- The Sprint Goal was not met, but the organization extracted value
from the process-improvement opportunity.
Again, note what is deliberately left out of the definition. A Sprint
Goal can be met even if the Sprint Backlog is not completed; by itself,
an incomplete Sprint Backlog does not mean the Sprint failed. Likewise,
a Sprint Review that doesn't delight stakeholders just means that the
the iterative feedback loop of the Sprint is operating as designed.
Of course, if the Sprint Goal was not met, and there's no silver lining
for the team or the organization, then it's fair to say that the Sprint
has failed. However, even a failed Sprint is rarely a total loss; there is
usually at least some residual value from the iteration, allowing even
"failed" Sprints to provide some marginal benefit.
Drawing Conclusions From a Single Failure
Analyzing failures is one of the purposes of a Sprint Retrospective. It
offers an opportunity to conduct a post-mortem and identify potential
improvements to the team's process.
From an overall project point of view, though, an isolated failure is
just a single data point. Until you have a pattern of failures, about
the only conclusions you can reasonably draw are:
- You have a potential process problem that should be carefully
- You have missed an opportunity to extract value from the process by
- You may need to re-estimate your Product Backlog and release plan
if you have insufficient slack in your project to allow for variance
Of course, if you really do have a pattern of failures, then it's up to
the team and the stakeholders to analyze why the process broke down
repeatedly, and whether the process or the project can be salvaged.