User Story Basics – What is a User Story?

What is a User Story? I’m glad you asked!

First of all, it’s important to say that User Stories are not a part of Scrum as defined in the required practices in the Scrum Guide. User Stories are but one way to represent Product Backlog Items in Scrum, and while it is the most popular method used, it is not the only method. Still, though, I would like to remind you that the User Stories practice is totally independent of Scrum, and thus it is not defined by Scrum. As such, everything else in this post is about the User Story practice and not Scrum itself.

Beware the common misconception!

There is a common misconception in the industry that a User Story is a sentence like:

  • As a <user> I want <some functionality> so that <some benefit is realized>.

THIS IS NOT A USER STORY!!! This is the biggest User Story trap in existence! See Trap#1 and #8 of my article on User Story Traps.

What is a User Story?

A user story describes functionality of a system that will be valuable to a Non Development Team(NDT) stakeholder of a system or software. User stories are composed of three aspects:

  • a written description or short title of the story used as a token for planning and as a reminder to have conversations
  • conversations about the story that serve to flesh out the details of the story
  • acceptance tests that convey and document details and that can be used to determine when a story is complete


What do they mean by Acceptance Tests?

Typically, in the context of a User Story definition, we mean tests that are represented by conversations, textual descriptions, tables, diagrams, automated tests, and so forth. When these Acceptance Tests are applied to the completed, implemented User Story, all of the tests should pass, and will thus prove that the story has been implemented correctly. If some functionality was not covered in a User Story acceptance test, then it wasn’t a requirement for that particular User Story.

Technically, in the context of a User Story definition, an acceptance test need not be automated or implemented. At the minimum, it should be described conceptually. The test should then be executed in order to prove the story and get acceptance, whether that be a manual or automated process. If your conceptual acceptance tests are described by one or more automated tests, then that is generally a much better practice, but not absolutely required.

Acceptance Tests should be automatable about 90+% of the time, though again, it is not required that they be automated. Having said all of that, when teams strive for development speed and quality, very few get far along that road without automating a large portion of their acceptance tests.

Acceptance Tests, in the context of User Stories, are also sometimes called Story Tests, Acceptance Criteria, Conditions of Satisfaction, and Test Confirmations.

Ron Jeffries, one of the co-inventors of User Stories and Extreme Programming (where the User Story practice comes from), has a good article that also describes User Stories in a basic way.

When do these Conversations and Acceptance Tests get created?

Typically, this happens in weekly Product Backlog grooming(also known as a Story Writing Workshop, Story Grooming, etc) sessions, but can also happen informally. The most effective backlog grooming includes some stakeholder/user representatives, the entire development team, and a Product Owner (Scrum) or Customer(XP). These sessions happen weekly and usually last 1-2 hours each. The goal of the sessions is to get stories that are “ready”, meaning the team has a shared understanding of the Acceptance Tests, and has the vast majority of the information they need to implement(code) the feature. See What does Product Backlog Grooming Look Like? for more on that topic. Keep in mind that sometimes a single User Story will be discussed in 2-3 grooming sessions before it is “ready”, especially if there are open questions or complex logic involved.

Frequently Asked Questions

Should I use a User Story to represent bugs/defects in a system?
The short answer is “it depends.” If it is a legacy or deferred bug, then yes, and it should end up on the Product Backlog(story points assigned). If it is a bug that was introduced since Scrum/Agile was put in place, then no, and it should end up on the Sprint Backlog(no story points assigned). See One way to handle Bugs and Production Support in Scrum for the longer answer.

Where do I get more info?

Handling Scope Changes Mid-Sprint in Scrum

The first thing about handling scope changes mid-Sprint is to recognize what type of scope change it is.

Bug or Production Support request?

If it’s a bug, or a production support research request, then my preferred method is to use One way to handle Bugs and Production Support in Scrum . As it says in that article, I hope you don’t need that chart. If you’re one of those teams where such bugs and production support requests are very rare (say, on average, once or less every 2-3 months), I’d say just do it and you can choose whether to make it a Product Backlog Item or put it on the Sprint Backlog. You’ll probably lean towards PBI if it’s a big thing, or put it on the Sprint Backlog if it’s a small thing.

Scope Change to PBI in Progress

If it’s a scope change to a Product Backlog Item in progress, my hope is that this means a new or changed acceptance/story test of some sort. If you’re not practicing Acceptance Test Driven Design, you should be! For you non ATDD types, the old school terminology for this is a “requirement change.” I’ve been around the block a few times coaching Scrum Teams on this scenario. My best advice is this:

  • If the change in scope is likely to increase the originally estimated size for the story by more than about 10%, then the change should be a new Product Backlog Item by itself. You may need the whole team to re-estimate the newly changed story.
  • If it is less than about 10%, then just change your acceptance tests, do it alongside the current PBI, and move on with life.

Swapping in the new PBI

If the scope change does result in a new PBI, then in rare cases where it is strongly warranted, a Scrum Team should be flexible enough to swap that PBI in and do it in the current Sprint. However, this usually means some other PBI will have to be swapped out of the Sprint as well. If these kinds of “swaps” begin happening regularly, then your team needs to do a root cause analysis on the swaps in the Retrospective.

  • In this scenario, don’t forget that the new, urgent PBI needs to be groomed, sized, and tasked out on the Sprint Backlog. Get all of your team together and you can usually do this in a matter of minutes.

Story Testing Patterns – My Recent Presentation at Mile High Agile

You can now find my recent presentation(along with all the handouts, etc), “Story Testing Patterns” on my website here:

Feel free to add any comments here on my blog.


One Way to Handle Bugs and Production Support in Scrum

Dear ScrumCrazy readers,

I need your help. I’m working on a Scrum strategy for handling bugs and production support on a Scrum team. This is the first draft of the chart below. I already have a couple of changes I would like to make, so I’d appreciate it if anyone could provide feedback on the chart below. Just hit the “comment” button below or email me directly with your advice. Thanks!

The Scrum Guide doesn’t directly address how to incorporate production support and bugs into your Scrum implementation. As such, it is left up to the implementers to decide how to handle it. The strategy(chart) below is one I’ve developed as a result of coaching teams that are new to Scrum.

I hope you don’t need the chart. I’ll say it again. I hope you don’t need the chart below. I hope that you have so few bugs and productions support issues arise, that you don’t even really need to worry about classifying bugs or coming up with a technique to handle production support. But, for the teams that need some guidance on how to incorporate these issues into their Scrum implementation, see below for one way to approach it. I also feel compelled to say that if you find yourself needing this strategy/chart often, you probably have some serious root cause analysis and retrospecting to do on these occurrences.

Why I include “Bradley” in the name.

Please be sure and read the “Preface” section on the chart below. There is an 8.5 X 11 PDF download below the image.

It’s a little difficult to see here on WordPress, so you might want to view it on my web site.

The Bradley Bug Chart
Download (8.5 X 11 PDF):

So, what did ya think?  Just hit the “comment” button(or “Leave a Reply” form) below or email me directly with your advice.

A User Story Checklist

Sometimes it’s difficult to determine if something is a User Story or not.  Not everything a software team does is a User Story.

In my other article, User Story Basics , I talk about the definition of a User Story.  I will use that definition to make a checklist of characteristics a User Story must have.

  1. Does the story describe new or changed functionality in the system under development?
  2. Is the functionality primarily of value to a stakeholder playing a role other than the role of “developer on the development team for the system under development”?  Said another way, is the functionality primarily of value to a Non Development Team stakeholder?
  3. Is there a fairly unique written description of the story?  (This can be just a couple of words, like a title)
  4. Have conversations about the story, that clarify story details, taken place?
  5. Does the story have acceptance tests that convey and confirm when the functionality of the story is complete, correct, and present in the system under development?

If you cannot answer “Definitely, yes!” to all of the above 5 questions, then it is almost always… NOT a User Story.

With respect to Question #2, I tend to define ¨developer” fairly broadly, like Scrum does.  From the Scrum Guide: “[Development] Team members often have specialized skills, such as programming, quality control, business analysis, architecture, user interface design, or data base design…”.  On some development teams, people who play a role of developer also play a role of “product support member” for the system under development.  In this way, sometimes User Stories describe functionality that is important to someone doing production support.  Other than this one exception, though, functionality and features that are primarily of importance to developers are almost always not considered User Stories.  On the other hand, there is nothing wrong with a developer suggesting some functionality to a NDT Stakeholder, and/or convincing a NDT Stakeholder that some functionality will be primarily of value to that stakeholder.  If that stakeholder agrees, then you can re-classify that functionality as a User Story… so long as you can say “Yes” to all of the other questions above.

A question that often comes up is, “Should Fixing a bug be represented as a User Story?”  The answer is, it depends.  The only question we might have trouble answering “Yes” to is #2.  The first thing you should ask is this: What (already delivered) User Story Acceptance Test(or tests) fails due to this bug?  If you can’t point to one specific acceptance test, then it’s probably a missed acceptance test(meaning one was overlooked when the story was originally implemented) or a legacy bug(a bug introduced before you adopted User Stories), in which case, the bug should almost always be represented as a new User Story.

Scrum Guide 2011 – Backlog Grooming as a Required Practice


In my previous article, I give an overview of some of the interesting changes incorporated into the 2011 Scrum Guide. One of the most interesting changes in my view is the inclusion of Backlog Grooming as a required practice. In my Scrum coaching experiences, the one practice that seems to help beginner Scrum teams the most is backlog grooming. In some cases, the practice itself makes many PO related obstacles highly transparent, but transparency is what we want!


Backlog Grooming: The Red Headed Step-Practice.

I think that many beginner Scrum teams have trouble deciding on how best to transition to Scrum. They focus so much on the major practices (Product Backlog, Planning, Review, Retrospective), that they don’t realize that backlog grooming can ease some serious Sprint pain. This idea that the Sprint Planning Meeting is the first time we hear about all new backlog items is absolute nonsense, but that’s how the pre 2011 Scrum Guide read to a lot of people. Will there be late breaking backlog items that might be presented for the first time at the planning meeting? Yes, but it should be rare to very rare.


Third Time’s the charm…

I’ve found that most teams seem to have the highest productivity on implementing a backlog item when they’ve had a chance to discuss the item 3 times, with the 3rd time usually being the Sprint Planning Meeting for the Sprint in which it will be implemented. Each time a backlog item is discussed(with the whole Scrum team present), it is decomposed a little further and open questions and risks are identified. In between these three discussions, people should take action items to answer these questions and mitigate the risks. These action items are ones that often take days in duration to answer, for whatever reason (answers from stakeholders, technical deep thought and investigation, etc), but don’t take a lot of effort for each action item. Throwing all of these action items into a 2-4 week sprint means you’re putting these long duration tasks onto the critical path, and that’s just not productive.


My Coaching Style for New Teams

When I coach a team that is just beginning Scrum, I actually start with backlog grooming first. I usually pick a point on the horizon 2-3 weeks out and say: “Sprint 1 will start on date X, and between now and then, I want you to continue working how you have been working, except that we’ll have a few training sessions between now and Sprint 1 so that we can hit the ground running(or “Sprinting,” if you prefer). Much of the time in those training sessions is focused on good backlog grooming techniques (and usually User Stories and Story Testing). It all starts with requirements!


Experienced Scrum Teams are Not Immune

Other non beginner Scrum teams also never seem to get to the point where they do backlog grooming well. I think many Scrum teams plateau when it comes to implementing Scrum, and this is really unfortunate. As Jeff Sutherland suggests in the Enhanced Nokia Test (aka “The ScrumBut Test”), the huge productivity gains for Scrum teams are in the last mile of implementing Scrum. If a team never gets to that last mile, then the high productivity promised by Scrum is never achieved. If your team wants to get highly productive, then your team needs to get really good at backlog grooming.


In My Ideal World…

In my ideal world, a team will first see a backlog item at a high level in a Release or other high level planning meeting. They will then dive deep into the item during a backlog grooming session near the beginning of the Sprint before its most likely implementation, identifying requirement and technical risks, logic questions, and other things that get in the way of fully decomposing the item into acceptance (or story) tests. Then, the item might be lightly touched on outside the grooming when unknowns become known, or maybe again in a grooming session a few days before the next Sprint. Then, at the Sprint Planning meeting, there are only very minor unknowns about the item, and the team is well versed on what is trying to be accomplished by the item. Knowing what work will need to be done for the item means the team can better plan their work for the Sprint. They can front load risks, parallelize efforts (automating the acceptance tests is a good parallel effort), and visualize the critical path for this and other items.


Where to Find Out More

I’ve written a series of articles on Backlog Grooming. <shameless plug> I haven’t updated them for the 2011 Scrum Guide yet, but nothing much about the 2011 Scrum Guide changed the practice itself, so probably 97+% of the material is still applicable.


For my articles on Backlog Grooming, see:

Part 2 – User Stories: Epics and Themes

Releases as Themes

Some teams uses release as themes, which his sometimes helpful with Release Planning and Release tracking via burndown charts. So, in our example above, we might decided to theme the current stories as follows (stories are listed in priority order)

Story/Epic Associated Themes
Pay by MasterCard/Visa Release Feb2011, Credit Card Payments, Online Payments
Pay by American Express Release Mar2011, Credit Card Payments, Online Payments
Pay by Discover Credit Card Payments, Online Payments
Pay via PayPal Online Payments

So, looking above, we know that MasterCard and Visa are targeted for the February 2011 release, Amex is scheduled for the March 2011 release, and the last two stories have not been targeted for any particular release. Since the Epics are listed in priority order, it is perfectly acceptable that we haven’t yet scheduled the lower priority Epics for a release. Much like a product backlog, the Epics and Themes near the top of the list are more fine grained(have been broken down further) than the epics and themes near the bottom of the backlog.

At this point, given the theming above, we may decide that we really don’t need the “Online Payments” theme any more. At the highest level planning, it was useful because we were considering online payments alongside with other Epics like searching for products and allowing users to post reviews on products. Once we broke the Epics down further into themes with smaller Epics, conveying “online payments” vs. “credit card payments” or “pay via PayPal” didn’t provide a whole lot of useful extra information. By now, the Epics have been discussed in planning, and everyone knows that credit cards and PayPal are the online payments we’ve been discussing As such, at this point I would drop the “online payments” theme because we just don’t really need it any more.
So, now we might have our themes as follows:

Story/Epic Associated Themes
Pay by MasterCard/Visa Release Feb2011, Credit Card Payments
Pay by American Express Release Mar2011, Credit Card Payments
Pay by Discover Credit Card Payments
Pay via PayPal

Wait! How come “Pay via PayPal” doesn’t have a theme? Because it doesn’t really need one. Let’s go back to the definition of Theme – a set of related user stories. We’ve already said that due to the collaborations that have already occurred, everyone already knows what we mean when we say “Pay via PayPal”, so it doesn’t really need a theme. Not every story has to have a theme, and themes are generally only useful to external stakeholders and the Product Owner, and generally only highly useful at high level planning like product road mapping and Release Planning.

At this point, we’ve pretty much used Epic and Theme where it’s most useful — at the road mapping and Release Planning levels. There is one more usage though that might be interesting to some teams.

Let’s say your Scrum team is planning to do “Pay by MasterCard/Visa” soon. Because they’re doing it soon, they would like to slice the stories into smaller chunks to allow their testers to get a first crack at testing something end to end sooner. The team has decided to slice the story into “Happy/Sad/Bad” paths. The bad paths will represent a story where the user goes all the way through the purchasing process but finds out that the credit card processing system(a 3rd party service) is down. The sad paths will represent cases where the card is rejected for various reasons (over the limit, invalid card, invalid card verification #, etc). The happy path will represent the cases where the card is accepted and the user is able to proceed with their order. The team decides to assign these stories to their related theme “Pay by MasterCard/Visa”. So, now the stories and the backlog looks like this:

Story/Epic Associated Themes
MC/Visa bad paths Pay by MasterCard/Visa, Release Feb2011, Credit Card Payments
MC/Visa happy paths Pay by MasterCard/Visa, Release Feb2011, Credit Card Payments
MC/Visa sad paths Pay by MasterCard/Visa, Release Feb2011, Credit Card Payments
Pay by American Express Release Mar2011, Credit Card Payments
Pay by Discover Credit Card Payments
Pay via PayPal

This is a valid use of themes but I find it to be overkill. Here is what I would do instead:

Story/Epic Associated Themes
Pay by MasterCard/Visa – bad paths Release Feb2011, Credit Card Payments
Pay by MasterCard/Visa – happy paths Release Feb2011, Credit Card Payments
Pay by MasterCard/Visa – sad paths Release Feb2011, Credit Card Payments
Pay by American Express Release Mar2011, Credit Card Payments
Pay by Discover Credit Card Payments
Pay via PayPal

So, what I’ve done is just rename the stories, which I think is more useful than creating themes every time one has a whim to do so. You could even rename them “Pay by MasterCard/Visa part 1″, “Pay by MasterCard/Visa part 2″, etc. This is why I believe Themes and Epics are really most useful at the PO and stakeholder level when release planning or road mapping. Keep them as high level grouping mechanisms, because that’s what they were really meant for. While the Scrum Team is involved at the Release Planning level as well, they will generally not care that much about the Epic and Theme concepts. They still care most about the stories that they’ll have to implement the dirty details for.

Prioritizing at the Epic and Theme level

Another way to make Epics and Themes useful is to use them to do high level prioritization with stakeholders. Generally, stakeholders don’t want to get into the nitty gritty of small stories. They really only care most at the higher level view. As such, having them help prioritize a fine grained Product Backlog might not be useful, especially if there are huge amount of stories. In these cases, it is useful to discuss Themes and Epics when prioritizing, which will then give the PO useful information with which to prioritize the smaller Sprint sized stories.

This is not to say that discussing small or fine grained stories with stakeholders is altogether bad, just that it might be bad in certain situations. Obviously you’ll have to gauge the situation you’re in and use the appropriate level of detail for your audience.

Link to full article:

What are your experiences with Themes and Epics?  Do you find them useful or unhelpful in any particular situations that I haven’t mentioned?  Add your thoughts in the Comments.

May the Sprint be with you!

User Stories: Epics and Themes


  • Epic- A large User Story, generally too big to fit into a single Sprint.
  • Theme – A set of related User Stories.
  • A story can be associated with one ore more themes.
    • Any story that belongs to more than 2 themes generally is overkill.
  • You can use “Releases” as themes.
  • The terms Epic and Theme are really only most useful during high level planning like road mapping and Release Planning.
    • Which means they are generally most useful to the PO and stakeholders, and less useful to the Development Team.
      • Exception: Using Releases as Themes is generally useful to the Development Team.
    • It is sometimes easier for stakeholders to discuss and help prioritize stories at the Epic and Theme level.
  • I walk through an example in the full article below.


Epics and Themes are useful when communicating at high level road mapping and Release Planning. That is to say, planning on a horizon that is a couple of months to a year or more from now. Because we are planning at the high level, and because the business stakeholders who are involved in such high level planning typically don’t want to get mired in details, Epics and Themes are useful concepts for high level planning. The concepts are also useful for stories that need to be planned and estimated (again, taking a high level view) where not a lot of detail about the stories is readily available.

Epic Defined

Epic – a User Story that is too big to fit into a sprint. Most often, this term is used to describe a very large User Story that will need to be broken down into smaller stories. Epics usually appear at the Release or Backlog Grooming Level. Epics can be useful when planing for a system on a further horizon than Release Planning. Some companies call this “Product Road Mapping” or “Product Visioning”, whereby plans are made to deliver major releases and features(Epics) over the coming year or so. At that high level of planning, you can’t afford to be working with stories that are fine grained(too granular for that level of planning) and small, so speaking in terms of Epics and Themes often helps. Practically speaking, a story is an epic if it is too big to fit into a sprint, OR if it’s unknown as to whether it is too big to fit into a sprint or not.

Theme Defined

Theme – a set of related user stories may belong to one or more themes. For instance, you might have a set of user stories related to administering a system, or a set of user stories that revolve around improving system usability. Conversely, a User Story can belong to one or more themes.
Often times, an Epic can be sliced into several stories. One way to remember that all of these sliced stories is related is to say that they belong to a particular theme.

An Example

Let’s say you have a store where you sell specialty books, the kind you can’t get at any old bookstore. Maybe they’re antique, maybe they’re religious, whatever. You’ve decided that you want to go online. Your first step might be to display some of your more popular books online, and allow people to place an order online. So, folks can add books to their cart, and create an order that gets emailed to your customer service team who then calls the customer for payment and to finish processing the order.
This might work fine for a while and you made some sales that you never would have made had you not gone online. However, sales online are beginning to get quite good and it’s taking a lot of human intervention to call customers and get their payment information. Instead, you decide it’s time to accept credit cards online.

So, you might start with an Epic titled “Pay for order online.” The initial High Level Story Tests(Sometimes called Conditions of Satisfaction or Acceptance Criteria at this high level) might be:
1. Test that customers can pay by Credit Card.
2. Test that customers can pay by Paypal.

That Epic could then be broken down into two stories:
“Pay by credit card”
“Pay via Paypal”
You could then say that each of those stories belongs to the “Online Payments” theme.

At this point, the dev team might say that “Pay by credit card” can’t be done in one sprint, and that “Pay by credit card” will be a much bigger story than “Pay via Paypal.” The PO then gets estimates on each of the stories, and decides, based on maximizing business ROI, that “Pay by credit card” is still the more important story. The PO might then leave “Pay via Paypal” alone for a while because she knows that it will be 2-3 sprints at least before it will be developed. Instead, she focuses on slicing the credit card story into smaller slices, hoping to eventually get to sprint sized stories and get the dev team working on accepting credit cards as soon as possible.

At this point, the PO might break “Pay by Credit Card” into the following stories:
“Pay by MasterCard/Visa”
“Pay by American Express”
“Pay by Discover Card”

One could still say that all of those stories belong to the “online payments” theme. One could also then say that these three stories also belong to the “credit card payments” theme.
This is just one example on how the terms “Epic” and “Theme” can be used. I don’t use the terms highly often at a Sprint level, but sometimes they’re very helpful in high level planning like Release Planning. They’re especially helpful when stories get sliced and then re-prioritized to where stories from the same theme are quite far apart in terms of priority on the Product backlog. Themes also can help the PO decide when to schedule releases of the software. Maybe they want to finish all of the stories in the “credit card payments” theme before they release. Or, maybe they want to break the “credit card payments” theme into a “credit cards phase 1″ theme and a “credit cards phase 2″. Maybe phase one is just MasterCard and Visa, while phase two is Amex and Discover.
Themes can be created with any subject or category. All you’re doing with a theme is saying that a set of User Stories is related in some way, and that you want to remember that they are related in that way.

I wouldn’t recommend going overboard with themes, though. Having a story that belongs to one theme is fairly common. Having a story belong to two themes is more rare, but still happens. Having a story belong to 3 themes is probably overkill or at the very least bordering on overkill.

Stay Tuned

In my next post, I will walk through an example of using Releases as Themes and discuss some other ways of using Epics and Themes.

Tips for Effective Backlog Grooming – Part 2

Tips for Effective Backlog Grooming

In my tips articles, I try to describe highly effective ways to fulfill the Scrum framework. The Scrum framework intentionally leaves holes that are opportunities for teams to fulfill the framework in the way that is best for a particular team’s circumstances. The Scrum Guide defines the Scrum framework, and my tips are in no way meant to define or re-define Scrum. My tips are based on my numerous Scrum coaching experiences, and I believe them to be consistent with the Scrum Guide.

Tip #1: Try to never schedule backlog grooming during the first or last 20% of the Sprint.

During the first 20% of the Sprint, the team is just getting started on this Sprint’s work, so you’ll want to give them some room to get a good start. During the last 20% of the Sprint, the team is working hard to get closure on the current sprint items, so that’s not really an ideal time to do it either. That middle 60% of the sprint is a good time to do backlog grooming.

Tip #2: Treat the backlog grooming meeting just like the first part of the Sprint Planning Meeting

  • Often called “The”What” of the sprint planning meeting, this part of the meeting talks about what will be developed in the upcoming sprint.
    • The PO presents the backlog items (often User Stories), the team ask for clarifications, and then the items are estimated by the team.
      • The PO then might indicate that priorities will change based on the estimate. Good! That’s the kind of collaboration that’s supposed to occur!

Tip #3: Make sure the PO knows that, during all of this sprint’s backlog grooming sessions, they will be expected to present enough work to last about 1.25 sprints or so.

The reason for bringing this much work to the meeting is twofold:
1. Often times PBI’s will be de-prioritized based on feedback in the meeting, so you want enough work leftover that you’ll be ready to fill a sprint.
2. It’s a good practice anyway to have a couple of finely groomed PBI’s beyond what you’re working on in a Sprint in case someone frees up and needs more work.

The PO may need to collaborate with the team to know how much work 1.25 Sprints worth is, but it need not be a lengthy discussion — just a very rough guess. Hopefully your team has seen the PBI’s at a Release Planning meeting or in some other backlog grooming discussion meeting. If not, then the PO can discuss the new PBI with a team member or two(informal product backlog grooming) to get a feel for the very rough effort involved.

Tip #4: The backlog items should be fine grained and well understood by the PO for this meeting to work well. Try to have an initial set of acceptance tests defined before the meeting occurs.

When the PO brings a backlog item to the meeting, what you don’t want to hear is, “Ok, I don’t have a lot of details on this item, but I’ve got the basic gist(or first draft) of it.” What you would rather hear is this “I’ve worked on this item and I have informally collaborated with both the customers and the team on it. I have a really good idea of the details of the backlog item as well as the acceptance tests for the PBI. It’s fairly solid, and I think there’s enough information there to start work almost immediately!”

Even if the initial acceptance tests are high level, that is better than no acceptance tests at all. The more the PO and team focus on getting to good detailed acceptance tests, the better.

Tip#5: Make sure everyone understands that estimates are not final until a PBI has been accepted into a sprint.

Since the team is getting a preview of the PBI’s, don’t let the team stress out too much on the estimates. Let them know that a PBI’s estimate is not final until the PBI has been accepted into the sprint. If someone comes up with new information between the Sprint Preview and the Sprint Planning Meeting, they are free to bring it up and re-estimate the PBI. This brings us to the converse of this tip.

Tip #6: Make sure everyone understands that priorities are not final until a PBI has been accepted into a sprint.

The PO is free to change the priorities of the backlog between the Sprint Preview and Sprint Planning Meeting. This is ok. We welcome late change, remember? In practice, though, I’ve found big priority changes happen rarely between the backlog grooming and Sprint Planning meeting, maybe 10% of the time or less.

While it may be frustrating for PBI’s to change priority often, remember that this kind of information is something we want sooner rather than later.

Tip #7: Keep your eye on the goals of the meeting

One of the goals of the meeting is that, when it’s over, the team has a handful of PBI’s queued up and ready to roll into a Sprint. All major questions have been answered (or at least assigned to someone to answer), and the team feels confident and knowledgeable about the upcoming work. Of course, like everything, not every last detail will be known, but it’s not for a lack of trying. At the end of the meeting you might try asking this of the team: “Of all of the PBI’s that were presented, a) which ones would make you feel very uncomfortable if you had to start tomorrow?and b) which ones do you not feel confident at all in estimating?” If any of these kinds of risk are identified, assign someone to help mitigate that risk before the upcoming sprint. This brings us to our next tip(available in Part 3 of this blog series — or you can click on the link to the full article below).

Link to Full Article:

Tips For Effective Backlog Grooming

What your backlog grooming tips?  Post them in the comments.

Tips for Effective Backlog Grooming – Part 1

Executive Summary

In a previous article, I discuss the answer to the question of Why do Product Backlog Grooming?. In this article, I discuss some tips for how to do effective backlog grooming. The primary benefits of backlog grooming are increased productivity and increased understanding/quality. Backlog grooming can be a little difficult at first when getting started, but the benefits are large and they appear very quickly, usually after just a couple of Sprints of doing it.

What the Scrum Guide Says

(Bold emphasis added by me)

  • “Product Backlog item estimates are calculated initially during Release Planning, and thereafter as they are created. During Product Backlog grooming they are reviewed and revised. However, they can be updated at any time.”
  • (Optional) “Tip :Teams often spend 10% of each Sprint grooming the product backlog to meet the above definition of the Product Backlog. When groomed to this level of granularity, the Product Backlog items at the top of the Product Backlog (highest priority, greatest value) are decomposed so they fit within one Sprint. They have been analyzed and thought through during the grooming process. When the Sprint Planning meeting occurs, these top priority Product Backlog items are well understood and easily selected.”

(Backlog grooming supplants most of what normally happens in the first part of the Sprint Planning Meeting)

  • “The Sprint Planning Meeting consists of two parts. The first part is when what will be done in the Sprint is decided upon.”
  • “Here, the Product Owner presents the top priority Product Backlog to the Team. They work together to figure out what functionality is to be developed during the next Sprint. The input to this meeting is the Product Backlog, the latest increment of product, the capacity of the Team, and past performance of the Team.”

Some Assumptions of this article

  • There are several kinds of Product Backlog Grooming, but in this article, I will focus almost exclusively on Weekly Team Product Backlog Grooming, except as otherwise noted.
  • I use Scrum terminology and a 2 week Sprint cycle in this article, but you can translate these concepts to other software approaches and iteration lengths.
  • I will use the more generic Product Backlog Item(PBI) term here, except where I make special mention of User Stories. Pretty much everything in this article also applies to User Stories.
  • Synonyms for Product Backlog Grooming: backlog grooming, sprint preview meeting, user story grooming, detailing user stories, user story conversations, etc
  • Any time I mention “backlog”, “backlog item” or “item” in this article, I’m referring to the Product Backlog and *not* referring to the Sprint Backlog.

Goals of Weekly Backlog Grooming

  • Come out with at least a few backlog items that are finely groomed
    • I define “finely groomed” as:
      • getting to an estimate that the dev team is moderately comfortable with.
      • getting to a deep enough understanding of the backlog item so that the dev team could accept it into a sprint with a moment’s notice.
        • Do not over-discuss or over-design.
      • splitting the PBI’s where the team feels appropriate — aim for items that are 2-5 person days based on whatever sizing units you use. See User Story Pattern – Micro Stories
    • If this is the last weekly grooming session before the next Sprint, then the goal is to have enough high priority items finely groomed to fill one sprint with about 25% extra work also finely groomed.
      • The 25% extra is to account for any last minute changes to the backlog (deferring items, removing items, estimate size changes, etc) as well as to have some “on deck” work in case the team needs more work later in the Sprint.
    • Get 90+% of details/acceptance tests(aka story tests) discussed, understood, and lightly documented where necessary, preferably as hand written notes on whiteboards (take a picture), cards, or stickies.

Having met your backlog grooming goals with flying colors, the only thing really remaining to do in the Sprint Planning Meeting is to task out each of the product backlog items and decide which items will be accepted into the sprint. You can also groom any late breaking PBI’s.

Who takes the lead in Product Backlog Grooming?

In short, mostly the Product Owner(PO). While the PO makes decisions about acceptance tests, logic details, and priority of the items, this does not mean it is solely up to the PO to groom the backlog and record details. Who takes on the legwork of the grooming is completely up to the Scrum Team. Said another way, the PO does have the responsibility to make sure the backlog items are groomed, but this doesn’t mean that they have to take on all of the legwork of doing so. Many PO’s do most of the legwork, but this is not a requirement, and will depend on your team situation. Ideally speaking, the “grooming” is a mostly verbal conversation, with only a few important notes or acceptance tests jotted down for each backlog item.

My rule of thumb is the Product Owner will spend roughly:

  • 1/3 of their time working with stakeholders to create and groom backlog items for the upcoming few sprints.
  • 1/3 of their time leading grooming activities with the development team for items that are in future sprints (focusing ~90% of this time on the *next* sprint).
  • 1/3 of their time working with the development team on backlog items that are being implemented during the current sprint.

Link to Full Article:

Tips For Effective Backlog Grooming

What your backlog grooming tips?  Post them in the comments.


Get every new post delivered to your Inbox.

Join 255 other followers

%d bloggers like this: