Diagnosing the Wellness of your Product Backlog

What do cars, human bodies, and backlogs have in common? All three need regular check-ups to stay healthy and useful. A product backlog is a key Scrum artifact. It holds all of the potential work the team/organization has not yet done that might be part of the product. One of the responsibilities of the product owner is to keep the backlog ready and healthy for the team.

A healthy backlog has 2 sprints-worth of sprintable stories. This rule describes the readiness of each story and the amount available for the team to work on.

Are your stories sprintable, aka ready?

1. Size

Size plays a key role in a story’s readiness. There’s no room (literally and figuratively) for epics to be in the sprint.

Product owners should decompose epics into feature stories and then sprint stories so the team can pull work as needed. Story points are a good way for the team to discuss the complexity or big-ness of features without taking time into consideration. Story points are also useful because product owners have a scope metric (total story points per sprint) to review during meetings with stakeholders.

2. Prioritized

Prioritizing user stories facilitates autonomy because everyone knows which story is next. In the picture above, you can see that the bigger chunks of stories are placed closer towards sprint planning and should be decomposed. Highest priority stories are at the bottom of the funnel.

3. Defined

An effective user story conveys the purpose for building the feature clearly. They typically follow this format:

As a <type of role>, I want <some goal> so that <some value>.

Notice that the sentence structure places the emphasis on the user as it is listed first. The team works together to write user stories, typically on notecards, at the beginning of the project. User stories also emerge as the project evolves. Acceptance criteria are added to user stories to further clarify the intent and to limit work by setting bounds. They can also be refined and changed under special circumstances if and when the PO has subsequent conversations with business stakeholders.

Amount

By measuring the productivity of your team, product owners are able to estimate how much work they should have ready in the backlog. This is what the term “velocity” is about – the amount of work the team has demonstrated it can deliver each sprint, averaged over several sprints. Since Scrum iterations are typically short (1wk – 1 mo), it will not take very long to get an accurate estimate of the team’s capability. For the first iteration, estimate by scope and capacity. Once velocity has steadied, product owners should make sure there is 2x the velocity ready in the backlog.

Symptoms of a sick backlog (and not in a good way)

1. Idle teams

Teams should be productive until the end(ish) of the sprint. Once they have met their commitment, there are other things they can be doing such as working on items from the previous retrospective or working on other technical items. That’s reasonable if there is only one day or a half-day left. If the team has three days left, they should be pulling stories from the backlog. A sick backlog has nothing ready for the team to do.

2. Invalid stories

As the project continues, stories and their acceptance criteria will change. Make sure that the backlog is fresh by holding backlog grooming regularly, either weekly or bi-weekly. Martin Fowler’s (one of the originators of Extreme Programming) “ConversationalStories” does a great job explaining the optimal relationship between PO and team and the conversations they should be having.

3. Unhappy developers and unhappy stakeholders

Even with Agile, there’s a chance that what is delivered is not what the stakeholders wanted resulting in angry developers, disappointed stakeholders, and sad product owners.

One way to avoid wasting time and effort is to close the communication loop between stakeholders and the team with stakeholder review sessions. I like to do stakeholder review sessions on a regular basis before backlog grooming with the team.

Stakeholder Review Sessions

Attendants: PO, Stakeholder, Team (optional)

Activities: Prioritize new epics and feature stories against existing backlog, review portfolio prioritization, identify release scope

Your body is a tool that should be kept in good order if you want it to reach its full potential. In the same way, the product backlog is a tool that should be maintained in order for the team to work efficiently and in an autonomous manner. To keep your backlog in good working order, it helps to have regular agility tune-ups, a service that will help teams optimize current processes and identify new ways to improve.