Agile myth: Writing user stories is Product Owner work

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:

Card

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.

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 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.

Confirmation

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.

Summary

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?