I am repeatedly confronted with the statement that only the product owner writes and prioritizes user stories. It is true that the product owner is the person who prioritizes the product backlog. But for reasons I don't understand, many people seem to be convinced that it is a core task of the product owner to sit down at their desk and write a user story until it is ready for a sprint. Is that really what the Scrum Guide?
The Scrum Guide defines the following tasks for the Product Owner:
- Product Backlog‐Einträge klar zu formulieren;
- Sorting the entries in the product backlog so that goals and missions can be optimally achieved;
- Optimize the value of the work done by the development team;
- Ensuring that the product backlog is visible, transparent and clear to all and shows what the Scrum team will work on next; and
- sicherzustellen, dass das Entwicklungsteam die Product Backlog‐Einträge im erforderlichen Maße versteht.
These described activities in no way imply that only the Product Owner writes the Product Backlog entries. Furthermore, the Scrum Guide:
The product owner can do the above work themselves or have it done by the development team. However, the product owner always remains accountable.
We do not want to blindly implement any written requirements, but those that help us to achieve our goal. If we understand a requirement as an invitation to a common conversation, this helps us not only to make the requirement understandable to our conversation partner, but it supports a common idea finding and can lead to a better solution.
No matter who writes product backlog entries, it is helpful for everyone to remember the 3C method. It is an acronym and stands for:
- C, like Card
- C, like Conversation
- C, like Confirmation
The 3 C's were created in 2001 by Jon Jeffries to distinguish the social user story format from the documenting requirements documentation formats (e.g. use cases). In detail, the 3 C's mean the following:
Card
This C means nothing more than writing down your requirement on a card to make it transparent for everyone and to include it in the product backlog. A small card such as a post-it is sufficient for this. Such limited space also forces us not to write a novel, but to focus on the essentials.
Conversation
We do not want to blindly implement any written requirements, but those that help us to achieve our goal. If we understand a requirement as an invitation to a joint conversation, this not only helps us to make our conversation partner understand the requirement, but it also supports joint brainstorming and can lead to a better solution.
Confirmation
The third C, Confirmation, stands for the jointly discussed acceptance criteria. The acceptance criteria describe what the customer expects from a successful implementation and how they can confirm that the implementation meets their expectations. This defines an acceptance test that can be used to demonstrate correct implementation.
Conclusion
So at this point we can say that the important thing about product backlog entries is
- Make requirements transparent, e.g. on a card
- Have a joint conversation to openly exchange ideas
- and to define a confirmation that we can use to check whether what was needed has been implemented.
But it is in the Scrum Guide the product backlog entries should not only be written by product owners.
Whether the person who ultimately writes the card has to choose the user story format to create a real product backlog entry is another matter, which we will deal with another time.
Finally, I would be interested to know who writes product backlog entries in your Scrum team?
Comments
Write a comment