A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.
Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.
My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.
In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.
We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.
1. Build your persona well
Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas – but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.
2. Focus on framing the problem
Often, a backlog defines the solution that needs to get built. Use the LEVER approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.
3. Generate multiple options for the same problem
Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
This typically changes the whole team’s perception of a delivery as a means to learn from the user – than as a way to ship stuff out of the door.
Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.
