Great Product Owners write awful backlog items
What makes a Product Backlog Item great?
I do not 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.
Imagine my younger self being able to review the current backlog items I am writing. This younger self would consider me lazy and possibly even incompetent.
The joy 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 leads to 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.
As expressed way better in the Agile manifesto:
Working software over comprehensive documentation
Special thanks to Willem-Jan Ageling for his valuable feedback.
