Skip to main content

Author: Daniel Gullo

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.

What’s Done is Done: User Stories

Sept20thFEATUREThe definition of done is a fairly popular (and sometimes emotional) topic in the Agileverse.  It seems everyone has an opinion on the matter ranging from “It depends,” to “Let the teams decide,” to a meticulously designed set of business rules and criteria that account for every possible scenario.  However, as organizations adopt Agile practices (and specifically, Scrum), they seek to leverage guidance from those of us who have already blazed the trail.  Why then is this such a complex topic?

One aspect is that the word “done” is overused.  We must distinguish between different contexts of “done.”  There is “done” at the story level, epic level, release level, product level, etc.  Each of those meanings of “done” has different criteria.   For the purposes of this article, we are only going to look at the done criteria for a user story.

Another aspect of the problem with done is perspective.  The word “done” is often used to mean “complete,” as in a Scrum team saying, “We are DONE with this story.” It’s also used to indicate acceptance, as in a product owner saying, “This story is done.” I typically teach and coach it this way: Don’t say “done.”  Instead, use “complete” and “accepted” for more specific indications of status.  This gives way to defining completion criteria and acceptance criteria (Figure 1). 

thumb_dan20th1

 

Click to expand image.

Figure 1.  Done Criteria = Completion Criteria + Acceptance Criteria

The criteria for completion are summarized as follows:

  • “Code complete” – as defined by the organization/teams
  • “Unit tested” – as defined by the organization/teams
  • “Peer reviewed” – as defined by the organization/teams
  • “QA complete” – as defined by the organization/teams
  • Documented (as needed; determined by the Scrum team through tasking at the beginning of sprint)

The Scrum team determines when the completion criteria have been met with the guidance of the Scrum master.  At that point, the story is considered “complete.”

The criteria for acceptance are summarized as follows:

  • The list of expectations for a specific user story as defined by the product owner prior to the beginning of a sprint.
  • The product owner may define these alone or with the help of the Scrum team and/or Scrum master.
  • For cases where acceptance criteria are not clear, a spike user story will be used to define the problem and acceptance criteria for a user story to be completed in a future sprint.
  • The Scrum team must agree to these acceptance criteria at the sprint planning meeting.
  • Minor changes to the acceptance criteria once the sprint is underway are acceptable as long as there is formal agreement between the Scrum team, Scrum master, and product owner
  • When the Scrum team believes these acceptance criteria have been met, the user story is ready for a product owner review (demo), which occurs throughout the sprint
  • The review (Demo) of each user story should NOT be left until the very end of the sprint

The product owner determines when these acceptance criteria have been met.  At that point, the user story is considered “accepted.”

This approach provides a framework that is modular and can be adaptable around the definitions of “code complete,” etc. but clearly delineates the roles and responsibilities associated with delivering and finalizing work.  If a particular organization is striving toward 100% automation of functional tests that become part of a holistic regression test suite, then “creating automated test scripts” would be expressed in the QA complete criteria.

Further, one group might agree on what “peer reviewed” means but not the “QA complete” criteria.  Using this modular definition, each group can customize these definitions to suit their team’s specifications.

As part of this exercise of defining “done,” I have also identified in the following diagram (Figure 2) the different stages at which events occur in terms of the definition of done:

thumb_dan20th2

 

Click to expand image.

Figure 2.  Definition of Done Process Mapping

The first column defines the event or phase during which the activity in the second column takes place.  Column three shows who is responsible for the action item in column 2.  In one of the teams I am coaching, there was a highly contentious relationship between the product owner and Scrum team, and this diagram helped sort through who was responsible for what and when.  This, along with a well-defined definition of “done,” set expectations and the conflict was neutralized.

Each organization (and team) must come to a consensus on what the definition of done is for their particular projects/products at various levels (story, sprint, release, etc.)  In the next installment of this series, I will explore what the definition of done is at the sprint 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.