Archive for the ‘Fundamentals’ Category

Agile Sprint Planning: A Well-Groomed Product Backlog

September 12th, 2012 2 comments

For me, one of the toughest challenges I face with a ‘young’ Agile team, is Sprint Planning.

Agile Planning, to some, seems like a contradiction in terms (like the old “Military Intelligence” joke). Yet planning is the essence of Agile, be it at the Portfolio, Release, Sprint or Daily level. Planning is the mechanism that allows a team to put a stake in the ground and say, “Let’s commit to trying to get to THAT place over there.” Planning provides a degree of predictability, or expectation, for a Product Owner. It allows a Marketing team to have some idea of when to ramp up the advertising campaign.  Planning is all about working out ‘the right amount of the right stuff at the right time.’

Today, I’ll share my thoughts about a Well-Groomed Backlog.

The Product Backlog is the list of stuff that the team will potentially work on. It contains feature requests, bug-fix requests, technical requirements (infrastructure, upgrades etc) and other team-related activities required in order to enhance or support the Product. I recommend you check out Mountain Goat’s definition .

Even though Product Backlog Grooming is ultimately a team endeavor, the Product Owner owns the Product Backlog. So there’s the first hurdle: do you have a ‘proper’ Product Owner, and do they know what their responsibilities are? Their primary responsibility is prioritization. Anyone can add items to the Product Backlog, but the Product Owner is the gate keeper of the ‘right stuff at the right time’. On several occasions I have been faced with a team where the Product Owner is actually a team director, tech lead or architect. They don’t own the Product, as such; they own the technical design, delivery and support of the application(s). What’s the problem? Well, in such a case, the Product Backlog tends to become heavily weighted toward product infrastructure and development environment tweaks. Business requirements can get pushed down the stack in favor of ‘improving the build process’ or ‘improving the architecture’. Given that we are trying to deliver Business Value, then having a Product Owner who is responsible for the usefulness/value of the Product is imperative. It may well be that improving the build process or architecture is a valuable investment, but this is a business decision that needs to be made within the context of all other backlog items. So, bottom line, make sure you’re following the Agile guidelines when it comes to appointing a Product Owner.

Now that you have an appropriate Product Owner, you (as a coach and/or scrum master), have to help them, and the team, understand what it means to keep the Product Backlog well-groomed. A well-groomed Product Backlog facilitates Release and Sprint Planning. The stories in the Backlog need to be prioritized in Business Value order, top to bottom (or at least as far down as your release horizon dictates). In addition, at least the next ‘Sprint’s worth’ of stories (the ‘right amount’) need to be appropriately sized, using relative sizing techniques such as point-sizing or ideal-day sizing. ‘Appropriately sized’ means that any story should be completable within one Sprint. ‘Completable’ means that it can be analyzed, coded, tested and accepted as DONE (per the Acceptance Criteria); that it could be deployed if necessary. I’ll talk about sizing in the next post. So now we know what a well-groomed Product Backlog should look like, how do we go about achieving that? Who needs to do what and when?

In an ideal world, the Product Owner has their hands on the Product Backlog helm. During the course of any given Sprint they should be taking a first-cut at the grooming for the next Sprint by reviewing and prioritizing the items in the Product Backlog. This can be achieved by allocating a few minutes a day, or it might be done in a concentrated effort prior to the next Sprint Planning Meeting. It is during that meeting that the team will look to the Product Owner to give enough information about each story such that the team has a clear understanding if the story is feasible for the next Sprint. If the Product Owner did not write the story, then they will have had to have talked with the author in order to understand enough to prioritize it. The team will need to understand what ‘done’ looks like; what are the Acceptance Criteria? They will need enough information to be able to ratify the existing relative sizing or to actually estimate a relative size on the fly.

In summary, a well-groomed Product Backlog allows a team to plan ‘the right amount of the right stuff at the right time’.

Thanks for reading.
Please share your thoughts (with a constructive, kind and gracious sense of purpose, please)


Categories: Fundamentals Tags: