New and Improved User Story Lifeycle Diagram — Free Creative Commons PDF download!

I had a designer friend update my User Story Lifecycle diagram, and she did a fantastic job!  You can download the PDF here:  http://www.scrumcrazy.com/lifecycle

New and Improved Diagram:

UserStoryLifeCycle_final_lg

The Older Diagram(also still available at the above link):

UserStoryLifecyclexm

Other Good User Story Links

A Visual Diagram of the User Story Life Cycle

This blog post is now deprecated.  Please see the new updated blog post:

http://scrumcrazy.wordpress.com/2013/06/13/new-and-improved-user-story-lifeycle-diagram-free-creative-commons-pdf-download/

 

My Preferred Agile, Scrum, and XP Resources

If you’re printing this post, it can be found online at: http://www.scrumcrazy.com/My+Preferred+Agile%2C+Scrum%2C+and+XP+Resources

A friend recently asked me this question:

What would you recommend in terms of the best book(s) to learn about Agile (Scrum) with XP practices? That is, if you had a team of developers who were newbies to Agile, Scrum, and XP, what books/articles would you give them to bring them up to speed on what they should be doing and how they should be doing it?

This question from my friend is a very tricky one, in that it is very broad and generic, and my friend gave me no extra team or organizational context to go on, so about all I can do is give a generic answer, and that is what I’ve done below. If you’re looking to combine Scrum with XP practices, be sure and see Kniberg’s book under “Scrum” below.

Don’t have time to read all of these? Well then, read the first couple from each category, and then continue working your way down each list.

My Preferred Resources

All are in order of my personal preference in each category.


Scrum

  1. The Scrum Guide (Must read for all)
  2. Deemer, et al. “The Scrum Primer”
  3. Cohn’s _Agile Estimating and Planning_ (Must read for Scrum Masters)
  4. Pichler’s _Agile Product Management…_ (Must read for Product Owners)
  5. Cohn’s _Succeeding With Agile…_ (Must read for Scrum Masters once they have a few Sprints under their belts)
  6. Kniberg’s _Scrum and XP From the Trenches_ (Note that there is a free PDF download of this book if you register with InfoQ – something I recommend anyway)
  7. Derby/Larsen’s _Agile Retrospectives_

XP (Extreme Programming)

  1. Jeffries’ “What is Extreme Programming?”
  2. Jeffries’ _Extreme Programming Installed_
  3. Koskela’s _Test Driven…_
  4. Martin’s _Clean Code_
  5. Feathers’ _Working Effectively With Legacy Code_
  6. “The Rules of Extreme Programming”
  7. Wiki entry on XP Practices

Agile/XP Testing

  1. Summary of Lisa Crispin’s Presentation to Agile Denver on Test Automation
  2. Cripin’s “Using the Agile Testing Quadrants”
  3. Crispin/Gregory’s _Agile Testing_
  4. Crispin/House’s _Testing Extreme Programming_
  5. Cohn’s “The Forgotten Layer of the Test Automation Pyramid”
  6. Osherove’s _The Art of Unit Testing_

User Stories (which originated in XP)

  1. My “User Story Basics” article and all of the links at the bottom of that article
  2. Cohn’s _User Stories Applied_
  3. Cohn’s _Agile Estimating and Planning…_ (Chapter 12: Splitting User Stories)
  4. Lawrence’s “Patterns for Splitting User Stories”

Special Agile Topics (if applicable)

  1. Deemer’s “The Distributed Scrum Primer” (If some of all your team is remotely distributed)
  2. My article entitled “The Role of Managers In Scrum” and all of the links at the bottom of that article
  3. Larman/Vodde’s _Scaling Lean Agile…_ (If your Agile transformation involves a very large organization)

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?

<Definition>
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

</Definition>

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?

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:

http://www.scrumcrazy.com/Presentation+-+Story+Testing+Patterns

Feel free to add any comments here on my blog.

.

Scrum Guide 2011 – Backlog Grooming as a Required Practice

Intro

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:

Tips for Effective Backlog Grooming – Part 3


Tip #8: Assign action items for any big risks or unknowns

For big requirements issues, this probably means assigning the issue to the PO. For big technology risks or unknowns, this means assigning a dev team member to research the issue at hand. The person assigned should be ready to report on the action item at or before the next grooming meeting or definitely before or at the Sprint Planning Meeting. This will usually involve re-estimating the item based on the new information — and that’s perfectly acceptable.


Tip #9: Remember that backlog items (and/or User Stories) are a collaboration between the PO and the team

The final responsibility for making sure the PBI’s are adequately detailed for the development team’s use falls on the Product Owner. However, don’t take that to mean it’s the PO’s job to do all that work. The items should be the results of a collaboration between the PO and the team(and also probably between the PO and the customers or end users). It is perfectly acceptable, and in fact encouraged, that the PO meet with 1, 2, or all members of the team to help detail a PBI, prior to a grooming session (what I call “informal backlog grooming”). Schedule meetings or have spontaneous collaborations as necessary, with the end goal being a well thought out, well detailed PBI when it is presented at a backlog grooming session. It is very atypical for a PBI to be one that is new to every single developer at a backlog grooming session. If this happens, consider it a bad smell and try to get developers involved earlier.


Tip #10: Remind the dev team to review the PBI’s to be discussed about 24 hours prior to the grooming session.

If your PBI’s are documented in any way before a backlog grooming session (such as on a wiki or on index cards), send a reminder to the dev team to review them so they are prepared to speak intelligently about them.

If the PO is making lots of last minute edits right up until the grooming session, much of the information will be seen for the first time in the meeting, which can make the meeting last longer. Ideally, the PO should target their editing efforts at being ready 24 hours prior to the backlog grooming session.


Tip #11: Feel free to split PBI’s during this meeting.

If anyone on the Scrum team feels the need to split items, during a grooming session is a perfect time to do it. You’ll probably want to re-estimate them too, and that’s fine. I hope it also goes without saying that if you split an 8 point PBI there should be no emphasis on making sure that the split out PBI’s all up to do 8 points. Just re-estimate them as if they were new, independent, PBI’s.


Tip #12: Optimize your time in the meeting.

For PBI’s that are well defined, just discuss and quickly estimate. For PBI’s that have already been discussed in a previous grooming session, you only really need to revisit them if there is new information about them. For PBI’s where there is new information, just discuss the new information enough to be able to give a new estimate.


Tip #13: Don’t be afraid to discuss a couple of items that are farther down the backlog

Sometimes there will be a need to discuss a backlog item that is further down the backlog in priority. Here are some reasons for doing that:

  • The PO needs to gauge the rough size of a PBI
  • The dev team needs to identify external dependencies that will need to be started on ASAP while waiting for the rest of the item’s details to be flushed out.

There can be many other reasons, too. While we don’t want to get into a habit of doing BRUF(Big Requirements Up Front) or BDUF(Big Design UP Front), thare are rare situations where looking at a backlog item that is farther down the road is advantageous to the team and the organization as a whole. Don’t be afraid to do it, but be wary of slipping back into BRUF and BDUF.


Tip #14: Strongly consider doing some informal backlog grooming before the full team backlog grooming.

  • Informal Product Backlog Grooming
    • The Product Owner will work with zero or more dev team members or stakeholders to refine stories and their priorities. Said another way, this is a lighter more informal way to groom the items in much the same way the grooming is done in the Weekly Team Backlog Grooming. This kind of informal grooming should be a daily, if not hourly, occurrence for the Product Owner.
      • When the PO gets together with development team members(early collaborators), she should strongly consider making sure that the three amigosare there.
        • Also feel free to bring stakeholders in to discuss.
      • Development team members should feel free to discuss relative sizes with the PO, but I encourage teams to wait to record any estimate until the entire team has estimated the item first. Said another way, the early collaborators should try not to skew the entire team’s estimates.

Tip #15: Don’t be afraid to introduce late breaking PBI’s. Try to minimize them, but embrace them when they happen.

Remain Agile! Some of the major goals around doing backlog grooming are to reduce unknowns and risks, but not all risks are easily identifiable before hand. Backlog grooming is not meant to eliminate risks, only to minimize them. Late breaking PBI’s will probably still happen(hopefully rarely), and they should generally be welcomed by the team. On the other hand, if it seems like most of your backlog items are late breaking, that is generally a bad smell.


Tip #16: Meeting Attendees: The entire Scrum Team + rare appearances by other key people

The meeting attendees should be, at the minimum, the entire Scrum Team. On rare occasions, you will need other key people, but prefer keeping non Scrum Team members(aka chickens) out of the meeting as a general rule. From time time to time, it will be useful to have a non Scrum Team member appear, but even those appearances should be limited. Try to limit the “other key people” to only attending while the relevant backlog items are being discussed.


Conclusion

If backlog grooming is done well, you can skip the entire “What” part of the Sprint Planning meeting and go straight to tasking out PBI’s in the “How?” part of the meeting. How’s that for a short planning meeting? Most teams will find that having regular product backlog grooming increases overall team knowledge and eventually increases productivity, usually by a large factor.

Link to Full Article:

Tips For Effective Backlog Grooming

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

Related articles on ScrumCrazy

Related articles on the web

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.

Why do Product Backlog Grooming?

Intro

Who likes long meetings? As a Scrum Coach, I ask this question of teams new to Scrum. I ask it mostly in jest, but also as an inoculation against people who will inevitably complain about lengthy Scrum meetings when first implementing Scrum. Obviously I turn it around on them. “I hate long meetings too, why do you think we have such long meetings? What could we do better?” Sprint Planning and Sprint Retrospective meetings can drag on and on and on unless they’re executed well. In addition, the ROI or value of these meetings can be horrible if they are not well structured. In this article, I attempt to make the case that Product Backlog Grooming can greatly enhance the value of your Sprint Planning Meetings, as well as keep them short and sweet.

Some of the best Scrum advice I’ve ever seen/given

One of the best ways I’ve found to greatly increase the value of Sprint Planning Meetings is to do Weekly Team Product Backlog Grooming. Because backlog grooming is not mentioned a lot in the Scrum Guide, and frankly not mentioned a lot anywhere else, teams have to come up with their own way of doing it. Below is my opinion based on my experiences coaching Scrum teams.

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.

What is Product Backlog Grooming?

In my experience, there are essentially three kinds of product backlog grooming.

  • Stakeholder Product Backlog Grooming
    • The Product Owner(PO) collaborates and converses with stakeholders to refine requirements for backlog items(usually focusing on ones that will be implemented soon, just in time) and to adjust priorities according to business value.
      • How far the Product Owner gets into detail is team, product, and stakeholder dependent.
      • Often times a PO will bring along a development team member or two to assist.
        • The development team member can provide insight into already existing system logic, as well as relative effort of backlog items, though she should refrain from making estimating comments for backlog items that have not already been estimated by the entire development team.
  • Informal Product Backlog Grooming
    • The Product Owner will work with zero or more dev team members or stakeholders to refine stories and their priorities. This should be a daily, if not hourly, occurrence for the Product Owner.
      • When the PO gets together with dev team members, she should strongly consider making sure that the three amigos are there.
  • Weekly Team Product Backlog Grooming
    • The Product Owner holds a roughly weekly standing meeting to groom backlog items.
      • Generally speaking, about 90% of this meeting is usually spent grooming the items for the next sprint.

The focus of this article is on Weekly Team Product Backlog Grooming, though I will often just refer to it as “backlog grooming”.

What does Weekly Product Backlog Grooming look like?

The weekly backlog grooming meeting is run just like the first part of any normal Sprint Planning Meeting. The Product Owner presents the backlog items, the team asks questions, and the team estimates them. Sometimes the items need to be split and re-estimated and that’s perfectly ok and even encouraged.

One important note here is that a backlog item is always open for re-estimation until it is accepted into a particular sprint. As such, if some information changes about a backlog item between the backlog grooming and the Sprint Planning Meeting, the team is allowed to re-estimate if they so desire. The same goes for the PO re-prioritizing backlog items between the weekly backlog grooming and the Sprint Planning Meeting. I’ve found this to happen in only about 5% of the cases, so it’s not a big risk. Besides, you’d rather these changes happen a few days *before* the next sprint than a few minutes *into* the next sprint!

Advantages

  • More time before the sprint actually starts to:
    • let the new backlog items “sink in” before final estimating and implementation.
    • optimize design, test, etc (i.e. team members pondering the issues in their spare moments for a few days before the sprint begins).
    • explore and resolve external dependencies
    • research/study up on
      • any technology hurdles.
      • any estimate risks like legacy code or code that hasn’t been touched in a while
      • requirement hurdles like requirement holes, ambiguous requirements, validating acceptance tests, etc.
  • The grooming forces the Product Owner to be well prepared for the next sprint and helps prevent a “Product Owner Bottleneck,” which is a worst practice.
  • If the Product Owner discovers something in presenting new items that inclines them to re-prioritize, they have a couple of days to collaborate with others and get that figured out.
    • The PO can then re-prioritize, queue up new items instead, etc

Disadvantages

  • If the Product Owner discovers something in presenting new stories that inclines them to re-prioritize, the team might feel like time was wasted or feel stressed due to the change. While we like front loading risk and knowing these things sooner rather than later, the team may feel a bit frustrated at times. However, that same frustration grows exponentially the longer the change is delayed, so this is definitely a desired disadvantage. It’s a good idea to remind the team that the pain now is smaller than it would be if we found out about it later.
  • It can be hard, at first, for some team members to “switch gears” at a time when they’re rockin and rolling on sprint N, to start thinking about sprint N+1.
    • It can take a while to get used to this type of cycle, but all of the teams I worked with liked it much better than a Sprint Planning Meeting that dragged on and on or didn’t provide enough value to the team.

Where do I go from here?

In a future article, I will give tips on how to maximize the effectiveness of your weekly backlog grooming.

Do you have other reasons you like or dislike weekly product backlog grooming?  Post them in the comments.

Follow

Get every new post delivered to your Inbox.

Join 266 other followers

%d bloggers like this: