There are many great moments in the life of a Product Owner, such as receiving thanks from stakeholders or the successful deployment of a new product, but this only comes from everyday hard work. And when I think about a Product Owner’s daily duties I always refer to The Scrum Guide for reference.

The Product Owner is the sole person responsible for managing the Product Backlog. – The Scrum Guide

The operative word of this quote is managing, in which there are many activities and one of them is to create proper descriptions of the tasks for developers. These tasks are often referred to as user stories or just stories. There is no doubt that this is a very important activity which is often postponed or neglected because it is considered boring or not creative.

What I agree with is that this is not rocket science, but I don’t agree that creating good user stories is not a demanding task. There are a couple of techniques which if correctly implemented, can dramatically improve backlog quality.

Start your work with 3C

This is also known as Card-Conversation-Confirmation flow. It is very useful when you are aiming to create a user story from only a concept.

• Card
  This refers to yellow post-its that Agile folks usually put on walls. What this really means is that you should start with a very generic title and make it visible for others.
• Conversation
  After sticking the post-it to the wall it will probably engage other people. They should speak freely what they think stands behind the title. Open discussion facilitates good ideas and helps everyone understand what the topic is actually about.
• Confirmation
  Prepare the first version of your notes and groom it with your group. Eventually, you will end up with a formal story description, that is clear to everyone involved.

INVEST in good user stories

It often appears that things that are clear to business people, are not clear at all for Development Teams. The Product Owner is the one that is “Clearly expressing Product Backlog items” (Scrum Guide again). He should be more than interested in creating stories that are clear for Developers.

‘INVEST’ is an acronym which describes the properties of a good user story:

• Independent
  The story should be as independent from others as possible. First and foremost it’s Acceptance Criteria (conditions that a software product must satisfy to be accepted) can’t rely on any external factors or any other stories. If possible, every story should be independent in order, meaning that you shouldn’t have to wait for starting it before finishing another.
• Negotiable
  The story should be an open invitation to collaborate. The description and requirements in the story should not be closed for negotiations. The Scrum Team should collaborate to deliver the highest value and not to fulfill perfectly described Acceptance Criteria.
• Valuable
  If the story is not delivering any value – then it should be deleted. There is no compromise here. However, it doesn’t always have to be direct value for your customer. As higher maintainability or reducing risks are also values.
• Estimable
  As a Product Owner, you are highly interested in maximizing ROI. This can only be done if you actually know how big it is so you can prioritize it correctly. It also helps everyone with better planning of their work.
• Small
  Here comes the tricky bit. I’ve seen a lot of very big user stories that take weeks to develop, but in my opinion in order to stay agile, splitting them into smaller parts is a must. We should focus on creating the smallest increments as possible, so an ideal solution for big tasks is to extract the bare minimum, implement, and evaluate the results.
• Testable
  At the end of the day, the whole Scrum Team needs to agree that the story was actually done. To do so, we need to somehow test it. If something is not testable, then we are unable to distinguish done from not done.

Set SMART goals

Good user stories are built upon precise goals, so defining accurate goals will help with creating clear user stories. You have probably guessed already that SMART is an acronym. This one, however, has many different explanations, and each of them stands for a slightly different set of values.

The following explanations are the ones I have found to be the most fitting:

• Specific
  The task should fulfill something. There has to be a specific goal to achieve, it cannot be generic or described imprecisely.
• Measurable
  You should be able to measure if you have already met a goal or not. “Site needs to be faster” is not measurable. But “Site will load quicker by 10% than today” is measurable.
• Assignable
  This doesn’t mean we need to assign a Developer right away, but eventually, we need to know to whom we address this task.
• Relevant
  You need to stop for a moment and decide here if this goal is really giving you value.
• Time-boxed
  Specify when you need the goal to be achieved. All goals should be time relevant.

Conclusion

If I would have to point out the biggest issue I have noticed in many stories, it’s the lack of business values. You can have the best description, but if you lack real value in a story, then it is pretty useless.

I have also heard that a good user story is one that is following a template: “as an Elephant, I need a trunk in order to drink”. This template is useful, but I encourage you to not fix on it – don’t enforce it in every single Story.

Good luck with managing The Product Backlog!

Enjoyed reading it? Then, you should read our amazing blog posts on agile product development, including: 

• Four good communication practices for distributed teams – ideal for those having an offshore development team.
• 6 mistakes you should avoid when starting a new digital project – great for product owners who’re just starting out with project management