When are Backlog Items “Sprint Ready”?

In Scrum, the Product Owner creates and maintains the Product Backlog which represents business needs in the form of backlog items. These items can be at various stages of refinement, generally with the vaguest ideas at the bottom and the most complete ones near the top. It’s in the best interest of the Product Owner to ensure that the top backlog items are complete enough for Developers to select during Sprint Planning. So the important question is: When is a backlog item “Sprint Ready”?

Let’s answer that question by identifying the classic parts of a properly constructed backlog item. First, there’s the User Story, a brief narrative that describes (a) who will benefit from the backlog item, (b) what business value is desired, and (c) why it is wanted. Here’s an example based on a website project:

As a member of the service,

I want the website to remember my username & password

so I can get to my account page quickly.

For some Product Owners, writing in this format is challenging or even silly so if providing the narrative isn’t possible, they can at least include answers to the three parts:

(a) Who: paying members of the service

(b) What: a feature that will allow the member to enter the website without logging in each time

(c) Why: so they can get to their account page quickly

The User Story is incredibly valuable because it provides the Developers with the context of the request and makes them partners in the delivery of business value, not just robots obediently processing requirements.

The second part of a backlog item are the Acceptance Criteria which define the conditions the Product Owner requires to consider the work complete and Acceptable at the end of the sprint. These are generally written at the business level, that is, in terms that convey the value for the “who” part of the User Story. They may also include more technical details where the Product Owner wants to be specific about what they want. Continuing with the example about usernames & passwords above:

  • The member must have the option of having the service remember or not.
  • The maximum time to remember a username or password is 30 days.
  • The ‘remember me’ service must be disabled when the browser is from outside the USA.

With an understandable User Story and clear Acceptance Criteria, most people would assume this is enough. But like the two-legged stool illustration, it won’t carry the weight of implementation efforts.

The missing third leg is represented by the Questions the Developers will ask and the final, definitive Answers provided by the Product Owner that clarify the backlog item. For example, after reading the second Acceptance Criteria above, a Developer might ask:

  • Did you want 30 calendar days or just increment the month? => 30 calendar days.

When documented as part of the backlog item, the Product Owner’s answer should immediately follow so any future reader gains the benefit of the new information.

Sometimes a backlog items seems perfectly clear until the Developers start coding, then questions related to implementation come up. Another Developer question might be:

  • What should happen if the browser blocks the storage of cookies? => Remove the option to remember the username & password.

As questions are answered, it may make sense to incorporate them into the Acceptance Criteria versus having a long list of Q&A. The first question regarding 30 days is a good example where the Acceptance Criteria could have been clarified:

  • The maximum time to remember a username or password is 30 calendar days.

Developer questions are inevitable, even the most experienced Product Owner may not think of all the details which is why it is important that the Developers have an opportunity to review upcoming backlog items and ask those questions. Ideally this is done during a Story Time Meeting that occurs prior to when the backlog items are likely to be selected during Sprint Planning but with with enough time for the Product Owner to update the Product Backlog. At this meeting, the Product Owner “tells a story” about upcoming backlog items and the Developers ask questions or provide feedback on how to make more clear.

In summary, the question of “When is a backlog item ‘Sprint Ready?’”, the answer is:

  1. When there’s a complete and understandable User Story and;
  2. there are clear Acceptance Criteria describing specific conditions with no ambiguity and;
  3. the Developers have had an opportunity to review the backlog item, provide feedback, and have enough of their questions answered to begin implementation.

That’s when the backlog item is truly “Sprint Ready”!

© 2012 William Patrick Swisher

This entry was posted in Acceptance Criteria, agile, Backlog Items, Sprint Planning, Uncategorized, User Story and tagged , , , , . Bookmark the permalink.

2 Responses to When are Backlog Items “Sprint Ready”?

  1. Just want to say your article is as astonishing.

    The clarity in your post is simply cool and i could assume you are an expert on this subject.

    Fine with your permission let me to grab your feed to keep updated with forthcoming post.
    Thanks a million and please continue the rewarding work.

  2. There’s certainly a lot to find out about this issue.

    I love all of the points you’ve made.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s