Again and again I am confronted with the statement that only the product owner writes and prioritizes user stories. 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 his desk and write a user story until it is ready for a sprint. Is that really what the Scrum Guide says?
The Scrum Guide records the following tasks for the Product Owner:
- Clearly formulate product backlog entries;
- Sort the entries in the product backlog in such a way 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 everyone and shows what the Scrum team will be working on next; and
- Ensure that the development team understands the product backlog entries as required.
These described activities in no way imply that only the Product Owner writes the product backlog entries. Further information can be found in the Scrum Guide:
The product owner can do the above work himself or have it done by the development team. However, the Product Owner always remains accountable.
This indicates that it makes sense for the product owner and the development team to work together on these activities. So both can and are invited to work together on requirements. This also makes sense because the development team consists of experts for the implementation of the product. Thus the team has very detailed knowledge and can write product backlog entries itself.
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 introduced in 2001 by Ron 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:
This C means nothing more than write your request down on a card to make it transparent for everyone. All you need is a small card like a Post-it. Such a limited space also forces us not to write a novel, but to focus on the essentials.
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.
The third C, the confirmation, stands for the acceptance criteria discussed together. The acceptance criteria describe what the customer expects from a successful implementation and how he can confirm that the implementation meets his expectations. Thus an acceptance test is defined, with which the correct conversion can be shown.
Thus, we can state at this point that product backlog entries are important:
- to make requirements transparent, e.g. on a card
- to have a common conversation in order to exchange ideas openly
- and to define a confirmation that we can use to check whether what was needed has been implemented.
But the Scrum Guide doesn’t say that product backlog entries should only be written by product owners.
Whether the person who ultimately writes the card must choose the user story format to create a proper product backlog entry is on a different sheet of paper that we’ll dedicate another time to.
Finally, I’d like to know who is writing product backlog entries in your Scrum Team Backlog?
That’s what our readers think
What a silly little article. The PO is responsible for conveying requirements. Without the PO doing the bulk of story writing, then requirements will go missed. Refinement is for when there is enough information for the development team to … refine the story. This article tries to be vague, so the clickbait title connects with the article. Sure, it isn’t solely up to the PO to write stories, but by and large they need to put in the initial effort so that they do have a card prepared for the conversation.
I still do not participate in an agile team. i´m learning and trying to implement with my partners and my leader team. It is interesting to know about myths and commun mistakes, just becouse i´m sharing this knowledge and reviewing the User Stories.
Agile provides a framework with which teams can maintain focus on rapidly delivering working software and providing true business value, even in environments where the technical and functional assets and landscape may vary or change routinely. We can say that Agile allows development teams to provide maximum business value through the delivery of truly valuable, working software that meets the business needs. How do we know that the software truly meets the business needs? Because all of the stakeholders are involved and quality and scope verification take place in short, iterative cycles. Deviations from the true purpose of a feature or piece of functionality can be identified quickly and corrected in an agile manner.