A few years ago, Mike Cohn promoted a user-story format of requirements. Since then, every requirement has become accustomed to being a user story in Scrum. Even then, when it is not considered to be a good one and even if it is not written in this format.

User Story

The User Story format is very simple.

As a someone

I want something

so I can have a value.

Little bit abstract, right? That is exactly how it should be:

  1. It gives developers the freedom to say how.
  2. It gives developers responsibility to say how.
  3. It has to be clear who is going to be using the requirement. If it is not clear and irreversible, the requirement may have a target group that will actually use it and will pay for it.
  4. It has to be clear what problem the requirement is going to solve. Not how to solve the problem. This is a job for developers, they are engineers after all. There may be several ways to solve the problem. From the fastest, cheapest to a complex scenario that is also prepared for the impact of the meteorite.
  5. You have to have a clear meaning, job, pain, respectively gain.

If you do not have the answer to the three parts of the sentence, you do not have a requirement. Then, there is no reason to do it.

Let’s look at a few examples from real life

As a user

I want a folder with pictures

so I can look through them.

When I review this story I think:

  1. Every user?
  2. Registered and unregistered?
  3. Paying users?

After chatting to the team we find that it is only for paying and logged-in, and of course, registered user.

As a logged-in paying user

I want a folder with pictures

so I can view them.

Why is it important to know who?

  1. Because the developer knows, that some authorizations will be needed.
  2. Because UX designer knows that you may need to show a lock icon for people who did not pay for the product.
  3. Because marketing knows who to prepare campaigns for.
  4. Because sales know who to reach and what problem to target.

What is next

…I want a folder with pictures…

Really a folder? Why does a Product Owner say that? He has UX designer in the team, he is the expert. So what problem does a persona solve with a folder? Why is one necessary?

  1. Publishing your photos.
  2. Sharing moments of your life. Hmm, it is getting quite vague, a moment can be a text describing a situation in life.
  3. Viewing pictures from my friends.

Wait! The first two are about sharing and the last one about viewing. Two different needs. Now we have two different user stories!

Let’s talk some more about sharing the picture.

As a logged-in paying user

I want to publish my pictures

so I can view them.

How can we simplify the sentence?

What is unnecessary in it, without additional value information? The word ‘my’. How will the system know which photos are ‘yours’? Maybe that is what the Product Owner really wants but we would be talking about machine learning and recognizing people in the pictures in such case. Is that so? Let’s say no, we will rather take the word ‘my’ away.

As a logged-in paying user

I want to publish pictures

so I can view them.

What is the value?

And now we are getting to the last part of the sentence. Is the only reason for viewing? Hmm, so my friends know the information I am experiencing. And why do they need them? Hmm, so they can stay in ‘touch’, at least virtually.

As a logged-in paying user

I want to publish pictures

so my friends can stay in a more personal touch with me.

If we asked ‘Why?’ once again, why friends would like to stay in a more personal touch with us, we would have come to a very vague cause. So that is enough for now.

To finish off…

  1. To find the right expressions use the ‘5 why’
  2. Remove optical noise, unnecessary words that do not add any significant information value.
  3. Try to find the user more explicitly. The worst is the ‘user’. Keep in mind that it is not supposed to be a developer, manager, ScrumMaster, Product Owner unless the system that is being developed is not for them.
  4. Beware of large
  5. Overall User Story should be realized by 3-5 days. Tests, documentation, etc. included. If it is bigger, try braking it down to smaller pieces so it still makes sense for a user.
  6. Validate the user, the need and causes using value proposition canvas. If something is missing in canvas, the requirement is probably useless. Less is more!
  7. Go out to users and see if they are having troubles with such a problem. A lesson of many Startup Weekends.