Do you love your Product Backlog? Do you stare at it for long periods of time with a dreamy look in your eye? Does the mere whisper of its User Stories make you shiver with delight?

No?

Don’t feel bad. Most of us don’t either. A good Product Backlog is hard to find and even harder to keep up. So how can we get to the point of “Super Fantastic Product Backlog Goodness”™? (Note: I actually have no legal trademark over this phrase, but I should because it is totally awesome.) Here’s a few ideas of how to build and maintain a better backlog:

It All Starts With The Product Owner

Since the Product Backlog is the responsibility of the Product Owner, it goes without saying that their ability and availability have a significant affect on the quality of your backlog. Stay tuned for a more in depth posting about choosing the right Product Owner.

Writing Good User Stories

There are plenty of good posts and online resources around writing good User Stories so I will only hit the high points:

• Size – One of the biggest problems I have seen teams struggle with is sizing stories appropriately. What size is appropriate? Well that depends mostly on your team. A good rule of thumb is that a story should be no larger than what you can finish in half a Sprint. I mostly see teams err on the side of too large since they have a hard time thinking a smaller story add legitimate value on its own.
• Roles & Personas – Too many times I see stories start with “As a user..”. Who is this user you speak of? Even if this story does apply to every single use who will ever use the system, the subtleties of how they interact with he system and what they expect can be different and imply other design considerations. Be sure to spend some due diligence figuring out the various types of roles for your application and some specific personas who would fulfill those roles.
• Clear Value – The third part of the User Story that outlines the benefit the user will gain from the described feature is often the hardest one to document. Smaller stories may seem to share the same benefit (and in some cases actually may), but don’t gloss over this part. Specifying the benefit of the feature helps with prioritization as well as giving the Scrum Team a better idea of why they are developing it.
• Acceptance Criteria – Even more so than the actual story itself, the Conditions of Acceptance are key for giving the Scrum Team a better idea of how the feature should work when complete which leads to better estimates, better test cases, and a idea of when the feature is complete. As a story is groomed and given more detail, turning these into actual high level test cases is a good way to make sure the team has a clear vision of how to meet the needs of the users.

Grooming The Product Backlog

The Product Backlog is not an artifact you work on at the start of the project and then ignore for the remainder. You  constantly groom the backlog, adding to it, reprioritizing it, and gathering the appropriate amount of detail as stories rise to the top (more on this later). If you do not spend a fair amount of time grooming the backlog it can grow into a gnarly Phil Spector-ish mess.

Most Scrum pundits proclaim a Scrum Team should spend 10% to 15% of the Sprint estimating the items on the backlog with the Product Owner. If you are running two week Sprints then that is almost 6 hours. I normally suggest breaking it up into two separate sessions so that if in the first one there are questions from the team the Product Owner has time to get answers. There is not a team I have met yet that does not initially balk at that. “Two more meetings each Sprint?!?! I’d rather spend that time coding.” You are going to spend the time either way.

When you are estimating stories, you are reviewing them together, discussing your approach, clarifying business requirements, etc. This information is invaluable for getting solid estimates and for helping to ensure you don’t get sucker punched in the middle of a Sprint due to an ambiguous story that suddenly becomes much bigger than expected. If that happens you will definitely spend more than a few hours figuring it out in the Sprint and jeopardizing other stories in that Sprint in the process.

Along with the Scrum Team dedicating time for estimating, the Product Owner must also dedicate time towards grooming the backlog each Sprint. This means holding story sessions with the stakeholders and users to get new stories, reviewing the priority of the backlog, and gathering more detail on stories that are high enough on the backlog to be slated for the next 2 or 3 Sprints. This is where the availability of the Product Owner becomes crucial. Poorly groomed stories tend to take the Scrum Team by surprise in Sprint Planning which causes them to be poorly implemented or run long.

Not All User Stories Are Created Equal

The big myth about Agile is that it allows you to “get more stuff done faster with less people”. Not true. And if someone tells you that you should punch them in the ear. Agile is supposed to help you get the important things done quickly with probably about the same amount of people. (If you disagree then you can find me and punch me in the ear.)

To ensure that you do the most important stuff first you must prioritize your Product Backlog items. This does not mean applying some business value metric and the sorting your backlog on it. The value of a backlog item has many different variables: business value to the user/company, the effort to deliver the feature, the ROI (business value divided by the estimated effort), it relation to other features that may need to come before it, and less tangible factors such as politics and solar flares. And on top of that it can change frequently. So prioritization needs to be part of any regular grooming.

A friend of mine compared a well prioritized backlog to a PEZ dispenser: you pop back the top and the delicious candy on top pops out!

Be Ready To Throw It All Away

Remember that a good User Story is a “reminder of a conversation”. It is not a specification to be strictly adhered to. Once you commit to a story and start working on it during the Sprint, the team and the Product Owner can refine it as needed. Any effort you put into detailing a Product Backlog item is potentially wasted time if done too early in the process and in too much depth. Try not to get too hung up on  the story and beware of sayings like “Where does it say that in the story?”.

If the story says A + B = C, but while you are developing it the team and the Product Owner find that A + B = X then that is what it is. Do you go back to the story and change it? In my opinion, no. So where would you capture this change? In the test cases. This should be tested for in some kind of test (unit, integration, feature, whatever). Static documentation of a story can grow stale if not constantly updated and let’s face it, who the hell wants to update documentation? A test, on the other hand, verifies what the code does and as we all know “the code is the truth!”

Now Go Be Super Fantastic!

Hopefully these ideas will help you go make your own totally awesome backlog! I’ll explore implementing a good deal of these concepts in Team Foundation Server in an upcoming post.