Article Menu

Tuesday, 27 September 2011 10:11

Grooming your Agile Backlogs for Success

Written by 
Rate this item
(0 votes)

Rgalensept27th1In 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. 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
  1. 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. 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
  1. 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. Another guideline is to have every User Story iteratively explored with the teams a minimum of 4x before sprint execution.
      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
  1. 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. 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. 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.
  1. 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.
  1. Grooming meetings focus on 3 levels of the Backlog
    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.
  1. 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!
  1. 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.
  1. 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.
  1. 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.

Rgalensept27th2

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.
  1. 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.
  1. 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.
  1. 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.
  1. 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”.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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!
  1. 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.
  1. 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.

Read 2004 times Last modified on Monday, 02 April 2012 16:26
Published in Robert Galen
Robert Galen

Robert 'Bob' Galen is a VP and Agile Coach at Deutsche Bank Global Technology in Cary, NC. He’s also the President and Principal Consultant of RGCG, L.L.C. He is seasoned agile consultant & coach who is also active in the agile community and regularly writes & teaches on all topics related to the agile methods. Bob also wrote the book Scrum Product Ownership, which is focused on that role and driving value in team delivery. Bob can be reached at bob@rgalen.com and networked with via his LinkedIn profile.

Latest from Robert Galen

More in this category: « STOP the Software Requirement Insanity Faultless Facilitation – Leveraging De Bono’s Six Thinking Hats »

Comments  

 
0 # jgw 2011-10-03 18:43
Good article. release planning seems to be a contentious issue so glad to see it mentioned here. How much detail is necessary for release planning. Should the stories be at the epic / feature level and then only broken down into stories nearer the development sprint or should the stories exist but only deatures / epics be sized? If there are multiple scrums involved in a release should an average velocity be used (assuming past metrics exist) to determine release capacity?
Reply | Reply with quote | Quote
 
 
0 # Bob Galen 2011-10-04 00:12
Responding to jgw -- I think the level of release planning really depends on the organization's needs for "accuracy", the time invested into the release, and the teams' capability to plan. I know that isn't specific, but each organization has to release plan for its own unique context. I would recommend staying at as high a level as possible. So, if you can plan releases at an Epic or Feature or Theme level, that's probably generally better than breaking stories into excruciating detail and planning at that level. If by "multiple scrums" you mean multiple teams sprinting multiple times, then I think velocity does come into play. I much prefer having each team use their own historical velocity in their release planning instead of taking some sort of average. Especially since each teams' velocity will vary and be unique. This team x team view also fosters buy-in to the release plan by each team. If you do average, make sure it's at a very high level and that you effectively communicate the variance that might result across your teams. Hope that helps, Bob.
Reply | Reply with quote | Quote
 
 
0 # sune lomholt 2011-11-11 05:37
great blog. We encourage our teams and PO's to do this as well and it becomes very obvious that the areas or projects where agile takes off is exactly those getting good at grooming. Furthermore, it seems like one very forgotten or secret or untold parts of agile. In order to deliver working solutions after 2-4 weeks you need really good specifications at sprint start and you cannot create these without the team because of the level of detail and its the team that knows what kind of information they need in order to deliver the required solution. This also touches another point - namely the anti pattern with a proxy Product Owner. Maybe this is not an anti-pattern? Consider large projects/system s/departments - in these cases you need a product owner for each team or at most two team. Thus if more than two teams are involved you need more than one PO and thus likely end up having several PO's. The typical answer is that there is one PO who hires other people to handle the teams (thus still having one PO) - but aren't these other people in fact proxy PO's? I have seen department having three teams with a PO for each team and then a PO team consisting of the team PO, the manager (overall responsible for the product) and business representatives . The PO team is then responsible for the prioritisation while the team PO's are responsible for obtaining the necessary specifications to the teams (i.e. detailing the PBI's with the team and the business). Hav e you written more about this (besides your book)? Do you have drawings of how this groming process interacts with the sprint (or delivery process)? rega rds Sune
Reply | Reply with quote | Quote
 

Add comment

back to top