Product Backlog. Get it Right Using These Slide Decks

Today’s slides digest is all about the Product Backlog. It is one of the 4 main Scrum artifacts — an ordered list of features that are needed as part of the end product and it is the single source of requirements for any changes to be made to the product. Getting it right is the basis for success, whatever the project or team.

Stories, Backlog, Mapping

The building blocks of a Product Backlog are User Stories. Dimitri Ponomareff, an experienced Agile coach, gives good advice about what makes up a good user story. He also compares use cases, requirements and stories, which is especially helpful for people coming from waterfall-style development. He also covers several efficient ways to manage the product backlog, e.g., blitz planning and story mapping.
One important note to remember is that Product Backlog is owned, managed and prioritized by the Product Owner. FlowHow’s experience from coaching different organisations shows that these responsibilities are very often overlooked and a mis-managed backlog becomes the root of many other problems. This is why we implemented an automatic check into FlowHow for detecting the Product Owner from JIRA Sprint data and give data-based clues whether the one who has this responsibility also does the work. The slide deck is here:

Keeping a Healthy Product Backlog

Dhaval Panchal, an agile coach in SolutionsIQ and agile42, shares good advice how to keep your Product Backlog in good condition. The main “ingredients” are:
  1. Having a single product backlog (not separate ones for bugs, new features, technical work, etc.)
  2. The backlog is stack-ranked prioritized list of items
  3. It is reasonably sized – don’t over-specify items in the bottom of the list
  4. Grooming the backlog before Sprint Planning – the backlog should be ready for the team (stories are clarified, split in a reasonable way and size, acceptance criteria is clear, etc.)
A note about #4: we have coached tens and tens of different software development teams and must admit that having the backlog prepared for the team before their next sprint really makes a difference. FlowHow product contains this automatic data-based check so you have to do less manual tracking to understand the health of team backlogs in your company.
Dhaval also lines out a good approach for your Backlog Grooming session, check it out here:

Backlog Blunders

Backlog refining is something that every team should focus on. But are you doing it well enough? Answer the 5 questions put together by Joe Combs (on slide 12) in the context of your own team and get ideas for improvement:

Agile Product Management

It is not enough if only the development team is agile, product management has to follow this mindset as well. Mike Cohn gives good advice in his Agile Product Management slide deck. One way to approach prioritization is to use Kano analysis. It categorizes features into 3 types:
  1. Threshold/baseline – must be present in order for users to be satisfied.
  2. Linear – the more of it, the better.
  3. Exciters/delighters – features a user doesn’t know she wants until she sees it.
He outlines the steps to conduct this analysis and concludes that you in your Product Backlog you should include all of the baseline features, some amount of linear features and also leave room for at least some amount of exciters. See more details here:

Summary

Developing software without a proper backlog is like building a house without proper blueprints – you just shouldn’t do it. So get started with better backlog management practices by going through those slide decks and taking action. If you use JIRA, go sign up for a free FlowHow product evaluation and see how it helps you to keep some of those obtained good practices on track.
Recommended Posts

Leave a Comment