Get certified - Transform your world of work today


Definition of a Successful Sprint

2 November 2015

Simas Torgovickis
Danske Bank

All teams should agree on their sprint goal at the planning meeting, which is coordinated by the product owner (PO). The most desirable goal is usually to prepare a complete PSPI (potentially shippable product increment). There might be tasks that are not related to the PSPI, but the main goal should be clear.

Completing the sprint goal(s), however, does not necessarily mean that the sprint was "successful." The variation in team members' definitions of "success" for a sprint can vary to a surprising degree. For example, completing all sprint backlog items (SBIs) does not automatically mean that the sprint was successful. (However, in many cases the team does not feel good about itself if there are unfinished tasks at the end of the sprint.) A high-functioning team should give some thought, as a group, to the elements that determine whether a sprint was successful or not.

Define sprint success

Every team has its own principles and rules, so the team should have its own definition of a successful sprint. Here are some good examples:
  • Achieving the most important sprint goals
  • Completing 90 percent of SBIs
  • No issues or hot fixes after the release
  • End users are happy after the sprint demo
  • Any other metrics pertaining to the sprint are met
There are many other possible elements of a "successful" sprint. Discuss yours with your team . . . and if you'd like, share them here.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.3 (7 ratings)


Tim Baffa, CSM, 11/2/2015 2:35:26 PM
What is the team's Definition of Done (DoD)? Those criteria should identify whether a sprint was successful or not.

The team should have some leeway in determining the contents of the DoD, but under no circumstances should a sprint be counted as successful if less than 100% of the sprint stories are completed.

A team and PO have the option to change the scope of the sprint as needed, but a "live" but incomplete story at the end of a sprint must result in a failed sprint. A good topic for the team retrospective (why wasn't the story finished, and what can be done in the future to ensure all stories are completed?)

A DoD is at the team level. There should NEVER be an individual definition of success that differentiates from the team definition.

Also uncertain why there would be unfinished tasks in a sprint. Any sprint tasks should be identified with a sprint story, and therefore if any task is incomplete, then the story is incomplete.

Below are some DoD criteria from past teams that I have served:

1. Code complete
2. Code well-written
3. Code review (4-eye test)
4. Developed software satisfies acceptance criteria and test cases
5. Unit tested (Verified by the developer that the code executes and it is defect-free)
 Test scripts / context testing completed (if applicable)
6. QA Testing passed
7. Automated testing built/passed (defect-free)
8. Other documentation when applicable
9. User-acceptance testing (TPM/PO)
10. Integration testing
11. Change management deliverables and events
12. Release-related deliverables and events (i.e. – regression testing)
Santosh Shaastry, CSP,CSPO, 11/9/2015 3:04:03 AM
Tim makes a great point about using Definition of Done as the standard to identify whether a Sprint is successful.

Point #9 is a very important one - Deliverable reviewed and approved/signed-of by Product Owner?

It is important that the Product Owner agrees that the deliverable meets the functional expectations.
Niroshan Madampitige, CSP,CSM, 11/11/2015 9:24:32 AM
While appreciating Simas's time invested on this article, i agree with Tim and Santosh...DOD is good enough to decide if your stories are successful. Id DOD is note met 100%, there is a potential issue to fix, so make your retrospection effective in identifying the root cause and then try and fix..Demo is another great ceremony to judge this, listed to product owner's feedback...
Pete Dowling, CSM,CSPO, 12/3/2015 11:02:18 AM
I disagree. The DoD only indicates whether the committed stories are done which is different from a successful sprint. There are many other factors to consider.
- Were the stories complete but the sprint was chaotic and organisation was poor?
- Where there any external distractions?
- Was there available team bandwidth to upskill and learn new technologies?
- Are the following being used: TDD, automated testing, CI, etc
I could go on. Getting committed stories to complete is just one element of whether a sprint is successful.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up