Backlog Items When the Product Is Still Undefined - Mike Cohn

Backlog Items When the Product Is Still Undefined - Mike Cohn

I get many of my ideas for tips from the questions people ask me in class or on calls. And I’m leaning on a real-life question for this week’s tip. Someone asked me recently:
 

“We’re working on an integration project, building out three APIs. We don't have proper user stories and are just figuring it out as we go. But it makes it hard to gauge progress.
 

“Is there a way we can still write user stories while we continue to figure things out?”
 

If you have a lot of open issues, one of the ways to structure a product backlog is to put those questions on the product backlog.
 

Issues as Backlog Items
 

Issues aren’t ideal as backlog items, but they can help teams get going. For example, maybe you have the following two issues that you know you need to solve before you can get started building a working product:
 

• We want to understand how to approach such-and-such problem
• We want to evaluate four alternatives and choose one approach

Put those onto your product backlog.
 

You may recall from my product backlog tip at the end of last month that I don’t normally want issues or questions on a backlog since they’re not true product backlog items. Why not? Because neither delivers a finished working product.
 

Instead, they’re decisions that the team needs to make in order to begin delivering product backlog items.
 

And sometimes, that’s just where a project is. And if that’s the case, issues can be the start of a product backlog.
 

Build a Working Product to Make Decisions
 

Try though, as soon as you can, to think of ways to turn those issues into user stories that do result in some piece of working product. In other words, reframe your issues and questions as user stories about building things that test hypotheses.
 

For example, the best way I’ve found to validate decisions is to build things. If I’m trying to figure out an architecture, I like to build things that prove the architecture is valid. A small build has two advantages: you’re delivering something and you’re using the work itself to help you make better decisions.
 

Let’s say we’ve done a design and it’s sketched out on a whiteboard. How do we know it’s the right design?
 

Well, the best way to know it’s the right design is to write one little thing based on that design. Then use that piece of working product to gauge whether the design is correct.
 

Building working product increments as part of evaluating options and making decisions will help you succeed with agile.

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/