In this blog post I want to share some guidelines around creating sound Product Backlogs for your agile teams. While this is certainly the realm of Product Managers or Product Owners, it often falls to the BA to assist or ‘own’ the Backlog details within agile teams.

In general, I find that teams’ spend too little time grooming. This leads to problems like –

• Painfully long sprint planning meetings
• Little thought being placed into designs
• Poor planning and execution
• Lack of creativity when solving business problems
• Poor forecasting

Think of backlog grooming as something beyond simple requirement definition. It’s inclusive of project planning, design & architecture, and strategy development. So spending some time here is a great investment—both in the short term sprint execution and in longer term release strategy development.

Product Backlog & Grooming ‘Quality’ Checklist

1. The Scrum Master facilitates the grooming meeting; not the Product Owner, driving everything. Core Scrum roles come nicely into play…

1. 1. Scrum Master as facilitator; process guide; coach
   2. Product Owner as business needs and value driver; defining the what and NOT the how (design) or how long (time)
   3. Team participates as a partner with the Product Owner in the real-time evolution of the Product Backlog

2. Backlog Length – the backlog should contain sufficient detailed items to entertain your team for a release; using team velocity and your release tempo as a multiplier. And sufficient epic items to accommodate 2 releases. (however you define ‘release’ in your organizational context)

1. 1. Another rule-of-thumb, is to target / limit the Backlog to somewhere between 50 – 100 User Stories
   2. Every backlog item should have a distinct, thoughtful priority – order

3. Grooming – run grooming meetings 2x a week. Remember the 10% investment guidance provided by Schwaber – so 4 hours per team member (individually and in meetings) per sprint week

1. 1. Another guideline is to have every User Story iteratively explored with the teams a minimum of 4x before sprint execution.

1. 1. 1. As a high level epic; at least a release before execution
      2. As a story or set of stories 3-4 sprints away from execution
      3. As a story 1-2 sprints away from execution
      4. As a story right before execution

4. For more complex work, new functionality, hard refactoring, etc. – ensure that sub-teams are identified that do off-line, collaborative grooming of these stories, focusing on

1. 1. Early design discussion
   2. Identifying story workflow & breakdown
   3. Capturing challenges & risks

and always leave sufficient work notes behind either in the story or on a wiki. Usually I capture this as a SPIKE. Remember two things about spikes:

1. 1. You should judiciously use Spike Stories as a way to engage your team in refining complex epics into meaningful stories and workflow. I’d say about 20% of User Stories are candidates for Spikes. Don’t short shrift them!
   2. Spikes should be run in the sprint before the sprint where you target their execution. This encourages some healthy look-ahead on the part of the team.

5. The Product Backlog should be initially set to priority order and always re-ordered by priority by the Product Owner. Order can be changed, but it should also be stable—representing the market/customer awareness of the Product Owner in meeting the business needs and leading towards team confidence. So don’t incessantly churn the Backlog as it lowers team confidence.

6. Grooming meetings focus on 3 levels of the Backlog

1. 1. Epic-Stories: breaking down larger scale Epics into parts; estimating their size, complexity and determining priority / workflow; probably no more than two releases in advance.
   2. Mid term-Stories: grooming stories that are 2-3 sprints away from execution. Having the team begin to think of design; execution efficiency,
   3. Short term-Stories: grooming stories “right before” their targeted sprint.

7. Run end-to-end Blitz planning as a means of gaining team feedback on workflow. I think it’s healthy to run Blitz Planning often. For example several times before a release is firmly planned. You can also do it mid-way in one release for early guess-timation for the content possibilities in the next release. Don’t be afraid to perform these end-to-end views often with your team!

8. Allocate time for bug fixing per sprint! Even if you set these up as “stretch stories” for the team…allocate the time as User Stories with an intent and acceptance criteria.

9. Allocate time for hardening and testing periods per sprint. These ARE User Stories and particularly useful when Blitz Planning. They should have acceptance criteria that are focused towards guiding the team towards the LOE required to achieve Done-ness.

10. Speaking of done-ness, there should be a clear definition of Done-Ness for the entire organization and uniquely for teams where appropriate. All story estimates and acceptance criteria should be created with this done-ness level in mind. Included with this should be the effort to professionally and responsibly complete each story.

What are some of the ‘smells’ of a well groomed backlog?

1. Sprint Planning is incredibly crisp, short and easy; usually taking 2 hours or less for a 2 week sprint. There are NO architectural or design discussions within the meeting—the relevant parts of these discussing having occurred earlier.

2. Team members are talking about Epics and Stories targeted for sprints 2-3-4 sprints in the future—nearly daily during each sprint and quite naturally aligning with the Product Owners’ vision.

3. The team easily contributes new stories to the Backlog to represent non-feature based work; for example: testing artifacts, non-functional testing work, refactoring, automation development, performance tuning, SPIKEs, etc.  They view it as a shared responsibility.

4. The team has a feel for where the product is going long term and map effort, designs, theme suggestions, and trade-offs towards that vision.

5. Each Sprint’s Goal is easily derived from the Backlog; i.e. there is a sense of thoughtful and meaningful themes that easily surface from within the Backlog. Sometimes think of these as “packages”.

6. The Product Owner includes team feedback (bugs, refactoring, improvement, testing, etc.) in EVERY sprint—in some percentage of focus. They clearly show the team faith in their feedback, judgment, and technical opinions.

7. The Product Owner rarely changes priority of elements because of size estimates. This doesn’t include breaking them into Now & Later bits. Illustrating that priority is mostly driven from external business needs that are translated into stories.

8. Blitz Planning is done every 2-3 weeks not only as a planning tool, but also as a risk / adjustment tool.  For XP folks, consider Release Planning as being a similar exercise. The point is end-to-end planning towards the next release milestone occurs quite frequently.

9. Teams are hitting stretch items and pulling in more work per sprint. There is an enthusiasm to deliver more towards the goals by trading off story sub-elements creatively.

10. The Backlog is mapped to the teams’ skills and capabilities, stretching them – yes, but not asking them to do things that they are not capable of doing either by skill or experience.

11. Every sprint the Product Owner is making micro-adjustments to scope based on interactions with the team. Always – looking for that Minimal Marketable Feature set!

12. The team is never surprised in Sprint Planning. Not even by a single Story.  I know, change is supposed to happen, but surprising the team with last minute changes…is not! Rather – wait till the next sprint.

13. The team feels they have a say in what’s on the backlog and the distribution of features vs. improvement items. But they can’t be solely parochial in their views. They need to make a business case from the customers POV, for all non-feature work introduced into the Backlog. And they do this willingly and well!

I hope you find the guidance helpful…

Bob.

Don’t forget to leave your comments below.