Skip to main content

What’s Done Is Done – Sprints

In the first installment of the ‘What’s Done Is Done series, we talked about what “done” means in terms of User Stories for various stakeholders in an Agile project. There are two aspects of “done” that are of primary concern: Completion Criteria and Acceptance Criteria. For this article, we will explore what “done” means for iterations, commonly referred to as “sprints” in Scrum.

Sprint Planning takes the form of a meeting involving the Product Owner, Scrum Team and Scrum Master. The Product Owner discusses the current Product Backlog, with a focus on the top-priority User Stories. The conversation involves the Product Owner’s explanation of the Stories, including the Acceptance Criteria and the Scrum Team seeking clarification so that they may make informed choices with respect to estimating and what they will commit for the Sprint.
The Scrum Team then provides estimates for the Stories, often in terms of Story Points using Planning Poker, and will then commit to what they believe is within their capacity for the Sprint. The product of this meeting is a committed Sprint Backlog, which represents the User Stories that the Scrum Team will work on for the Sprint.

The Scrum Team also uses this opportunity to create Tasks for the User Stories. This activity takes place during the second half of the Sprint Planning meeting and may or may not involve the Product Owner. As the Sprint progresses and User Stories are completed, they will be demonstrated to the Product Owner who then confirms that each User Story is “done.”

It may seem superfluous to have a discussion about “done” when dealing with Sprints, which are defined as time-boxed iterations. One might ask, “Isn’t a Sprint ‘done’ when the two weeks (or whatever duration) are over?” The short answer is “Yes, a Sprint is ‘done’ when it has run its originally scheduled duration.”

The sticky part comes into play when the Sprint is over but there are User Stories that have not been completed. Does the Scrum Team get credit for partial Story Points completed? Do the full amount of points carry over with the User Story to the next Sprint (or whatever Sprint the User Story is moved to)? Can the Sprint be extended if the Scrum Team was “close”? Before we answer these questions, let’s look at the initial commitment by the team, since this will ultimately impact what is completed within the Sprint.

When a new Scrum Team is formed, there is no collective past history to draw upon that indicates how much this team typically accomplishes. As time goes on, this “Team Velocity” tends to emerge. Let’s say that we are looking at Team Sigma and their velocity after 15 Sprints is 17 Story Points (SP). Initially, in Sprint 1, Team Sigma didn’t know that its velocity is 17 SP. They had to make a best effort at what they thought they could accomplish. They may have selected 20 SP as a nice round number and target. When Sprint 1 ended, they weren’t able to accomplish all of the Stories. Let’s further assume that the story they were not able to complete was 5 SP and that roughly half the work was “done.” Should they have taken the credit for something that is 50 percent complete?

No, they should not claim 2.5 Story Points because the point of the Sprint is to deliver potentially shippable features. That story is only half “done.” While 2.5 Story Points of work might be potentially shippable, that’s not what they initially planned. It is important moving forward for the team to take note that they actually accomplished 17.5 SP for that Sprint — doing so will help them come up with a better estimate for the next Sprint.

Given that the incomplete story is 5 SP but is “half done”, it makes sense for the team to keep the 5 point estimate but factor-in that item as if it were 2.5 SP. That is, when they plan, they will still plan for 20 SP, but they know that really, the 5 SP story is only really 2.5 SP worth of work remaining. That way, they are more likely to accomplish everything planned for in this Sprint.

The continuity that we are striving for in taking this approach is the work itself, not the accounting process for documenting the work performed and work remaining. The story is kept as a single unit with all its original tasks so that nothing is lost. When we start to split stories, there is overhead in trying to figure out what was really done and what wasn’t. and there is significant risk that the second half of the story will be pushed out and never completed. Assuming the first half of the work is not truly shippable without the second half, we are left with waste in the form of useless code.

Another possible scenario might arise where the Product Owner asks the team for a demo of the story that is 50 percent complete and determines that it is “done” from their perspective. If there aren’t any significant technical activities remaining, which would accumulate in the form of technical debt, the team can close the story and zero-out the work remaining.

Ultimately, the Sprint is “complete” when the time-boxed duration is over. It is “done” or “accepted” when the Product Owner has accepted and signed-off on all the stories in the Sprint. This doesn’t mean that the Sprint should be extended or discounted if there are discrepancies from the Product Owner. It means that there may be stories which carry-over into future Sprints. The way to reduce this risk is to provide demos to the Product Owner early and often throughout the Sprint. Following this practice eliminates surprises at the end and allows the team to fix things that aren’t up to snuff before it’s too late.

It’s important when considering these factors that the project team does not lose sight of the overall product vision. Yes, it’s important to define what “done” means at various stages in the life cycle. However, these definitions should add value to the product and, in the end, the delight of the customer.

In the next installment of this series, we will discuss what “done” means at the Release level.

Don’t forget to leave your comments below.

Daniel James Gullo, PMP. CSP, CSM of Trinacria Consulting is a proven leader in the field of Information Technology and Information Systems who advocates and evangelizes best practices and quality for projects in all areas of business.  Specializes in delivering software development and testing projects which are on-time, under-budget, and high-value. A professional with demonstrated success in Agile and traditional project / program management, business analysis, quality assurance, and consulting services.  A highly praised and recommended consultant with an extensive history of satisfied customers and clients.  Fiscally minded with both local and global experience.  Open to travel both domestically and internationally.  Effectively manages teams and resources around the globe both on-site and remotely.

Comments (5)