Great Product Owners Write Awful Backlog Items
What makes a Product Backlog Item great?
I don’t mean great as in delivering a lot of value. I mean great as in a perfect vehicle for expressing what you want to deliver.
My philosophy of writing backlog items has taken a 180 degrees turn compared to when I was starting out.
If my younger would have been able to review the Product Backlog Items I’m currently writing, they would consider me lazy and possibly even incompetent.
What changed in my approach over the years?
The Joy (and Misery) of Writing Impeccable Backlog items
When starting out as a Product Owner, writing great Product Backlog Items was my superpower. My previous experience as QA Engineer and Business Analyst benefited me a lot. I took great pride in writing concise Product Backlog Items with complete acceptance criteria.
I spent a lot of time writing User Stories. It made me feel great when all tickets were clear and the Development Team did not ask questions. I thought my developers should be happy with my effort and detailed explanations.
Except that I was all wrong. I would now consider my backlog items to both be bad and wasteful at the same time.
So how should you write Product Backlog Items?
It’s Not About What You Write Down, But What They Understand
“The sun is the width of a human foot.”
― Heraclitus, Fragments
A great Product Backlog Item starts a conversation. The goal of this conversation is to establish common understanding. It is impossible to perfectly describe what you want to build. The best you can do is try to get everyone on the same page and reach consensus in their mind.
As I become more experienced as Product Owner, I spend considerably less effort writing Product Backlog Items. Sometimes I even feel a bit lazy when I present my Product Backlog Items.
Product Backlog Items are not complete specifications, exhaustive requirements or a contract. It is okay if they are incomplete. As captured much better in the Agile Manifesto:
“Customer collaboration over contract negotiation.”
It is more important to reach your goals than restricting yourself to the initial contract as described in the Product Backlog Item. The best way you can realize this is by reaching a state of common understanding with your team about what you want to achieve.
Collaboration Produces Better Common Understanding
Imagine that by some stroke of luck you have spawned a perfect Product Backlog Item. You discuss it with the team and afterwards everybody is silent. The whole team is nodding in unison. Life is smiling at you and you feel great. This does not mean you have reached common understanding with your team.
As Confucius has phrased much better:
“I hear and I forget. I see and I remember. I do and I understand.” — Confucius
Collaborating and writing a Product Backlog Item together increases understanding. It’s not something they hear from you, it’s something they actively worked on. It is a product of their own mind. This means it is now a collective work product instead of an individual one with some collective contributions sprinkled on top.
In the end what matters most is what the team remembers and understands, not what is written down.
Update Your Product Backlog Items As More Is Learned
“We learn by doing because we do by learning.”
― Saji Ijiyemi
Before you start working on a Product Backlog Item, you usually lack information and understanding to describe it perfectly. When performing complex work, you often need to update Product Backlog Items as more is learned.
After all, the Sprint Backlog remains flexible after the Sprint Goal is set, unless it endangers the Sprint Goal. The Product Backlog is always open to be changed as more is learned. As you gain more knowledge, update your backlog items to reflect this.
No need to go for first time right, as you can add more later.
Spend Less Time Writing and More Time collaborating
Trying to write impeccable Product Backlog Items without involving your team is wasteful. Even with all the information in the world, it is not possible to describe everything perfectly as the humans who write and read are fallible.
Even if you would write something down perfectly, it’s not about what you write down, but what your team understands. By collaborating and writing a Product Backlog Item together you create the most common understanding. It stops being just a work product of the PO, but becomes something belonging to the whole team.
When you start working on a Product Backlog Item your understanding will grow as more is learned. You will have more information to describe it better and you may find out there is a better way. Update your backlog items as more is learned, instead of having to rewrite everything because your assumptions turned out to be incorrect.
You know the least about the work you’re undertaking before starting the work. Don’t limit yourself to the narrow understanding you have before doing the work.
Special thanks to Willem-Jan Ageling for his valuable feedback.
While I agree in concept I wished you'd have taken it one step further in your story. When you were writing "great" user stories, and there were no questions, what was the outcome of what was developed? If the functionality met all of your needs and the needs of the users, then one could argue add'l collaboration wasn't required because you documented it well enough for the Devs to understand completely. And then one could argue if all that detailed work was a good use of your time as the PO. It's no so much about the process, but the outcome. While I love collaboration refinement sessions, which I agree tend to result in the best products, some individuals and teams are simply not highly engaged during refinement due to cultural differences. Does that mean you force the conversation? Or, is it better to provide great detail as long as the results are good?
I agree on the update part and I've found the best way is to one more update once you're done. It's easy to forget updating a story once you're (nearly) done with an item, and if you ever look back why certain things were done, the last changes & pivots are nearly always missing.