Get certified - Transform your world of work today

Close

Ready, Set, Sprint!

Gaining an understanding of the Definition of Ready

4 November 2015

race-starting-line-120726-jpg-(JPEG-Image-575 × 375-pixels).jpg

In the Agile world, most teams should understand the value of getting something done and defining the associated stories. Often, though, teams are challenged to put such a definition on an item so that it is defined as ready to get from the product backlog into a sprint backlog. This article is not only about the Definition of Done (DoD) but more so about the Definition of Ready (DoR), so that teams can be better prepared for sprint planning.

Sprint planning preparation was a consistent theme with a well-established Agile team that I spoke with recently. The area I honed in on was the fact that the teams were often struggling to do sprint planning effectively because they didn't regularly and effectively make sure that their stories passed through certain tollgates in backlog grooming prior to being planned for a sprint commitment. Frustration, wasted time, and sprint fallout were the consequences of not making sure that stories "paid their tolls" to get from the product backlog into a sprint backlog.

These tollgates are important to making the transition from the product backlog to a sprint backlog. Not passing through them correctly is a common problem that causes issues later in the cycle. This can largely be resolved when the entire team gains an understanding of what is acceptable to talk about in sprint planning versus what is not ready to discuss.

Enter the DoR. The DoR is crucial because it can go a long way toward avoiding sprint fallout -- meaning that a user story is not complete at the end of the sprint and carries over to the next one.

How might a team determine a story's DoR and its related tollgates? There are, indeed, certain tactics that you can employ to define a story as ready, and I'll provide some examples . Typically, a ScrumMaster might use these tollgates to check stories in the backlog with the team prior to sprint planning in order to ensure the following:

Was the item prioritized by the business product owner?
The team always wants to work on the highest-priority or highest-value items. If the team doesn't understand the item's priority as defined by the product owner, the item should not enter the discussion for sprint inclusion.

Is the user story clearly written?
Use the recommended format to define a user story: "As a type of user, I want some functionality so that some reason."

So much value is placed in wording stories this way, and it is often one of the things teams avoid doing, or stop doing at some point. The entire team can quickly get context and sense of value from merely trying to construct a story by following this format.

Was the breakdown of the story effectively discussed?
Is this story too big to understand? Can it be done in a single sprint? Should it be an epic with smaller child stories instead?

Is the story estimated?
At the story level, a story point estimate (man-hour estimates equivalent to a Rough Order of Magnitude will suffice as well) should be established prior to sprint planning. This should come as the result of backlog grooming sessions and/or technical brainstorming sessions.

Does the story have clear acceptance criteria?
Acceptance criteria help with another definition: the DoD. From the business product owner's perspective, this should define how he or she sees it as complete. There's also a format the team can step through for this defined acceptance criteria as well, stated as: "Given some initial context, when some actions performed or event occurs, then ensure some outcome."

Have external dependencies been discussed?
Are these meetings with other teams necessary? Are research spikes necessary?

These checks that are used to ensure that a story is ready for sprint planning will go a long way toward making your sprint planning sessions much more productive and pleasant. I highly recommend going through these tollgates to achieve a DoR for each user story in your product backlog.

References
Definition of Ready: http://systemagility.com/2011/05/17/definition-of-ready/

Definition of Done: http://www.scrumguides.org/scrum-guide.html

Death, taxes, and estimates: https://www.scrumalliance.org/community/articles/2015/july/death-taxes-and-estimates

Sprinter image source: http://i.livescience.com/images/i/000/029/369/i02/race-starting-line-120726.jpg

 


 

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: 4.5 (4 ratings)

Comments

Tim Baffa, CSM, 11/4/2015 3:58:38 PM
Good article on DoR.

The INVEST acronym is helpful in crafting a workable DoR.

A key benefit from User Story statements is in defining the role. Often, the same business benefit (what) can have different acceptance criteria due to different roles being identified.

I've also had some success with User Story Statement variations, like "In order to... As a... I want". Often, with the traditional "As a... I want... So that" approach, the "As a..." portion almost becomes a throwaway (as a USER, I want...). Changing it up to put the business issue in front (In order to...) can stimulate discussion and improve identification of different roles for the story.
Meghan Robinson, CSM,CSPO, 3/17/2016 4:12:20 PM
Would you be okay with us highlighting this article on our new AgileCareers Blog?

You can view the blog here: http://membership.scrumalliance.org/blogpost/1322603/AgileCareers-News

I look forward to hearing your response! Thanks.

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

Subscribe