5 useful tips for creating your user stories

What are user stories?

At Crystalloids, we work with Scrum, which is a widely used methodology for managing software development projects.

User stories are in the centre of the whole scrum methodology, telling everyone in the scrum team what needs to be done, for whom and why, when working on a software project for a customer.

In short, user stories are short sentences that describe the need for a feature, told from the perspective of the user who desires the new capability. Mostly they are written on index cards and arranged on the office walls, but many of us also use software to manage the tasks online.

Although they might look simple and easy to come up with, there's a lot of complexity behind these short lines. The product owner is there to manage and write down the stories. But that doesn't mean he's the only one in charge...

We wrote down five useful tips that will help product owners and their team create the best user stories and avoid the pitfalls that many tend to make.

1. Don't just hand your stories over; discuss them!

The primary goal of a user story is not to just transfer a written requirement which tells a delivery team exactly what they need to do. No, it's triggering discussion, endless discussion. To get the iterative method of scrum going, a conversation between different parties within a Scrum team is necessary when creating user stories. Because only then, all the fields of expertise of different people are in best use.

If you just write down your user-stories and hand them over to the team, the chances are big that they will be interpreted differently. By discussing them, it gives you the opportunity to check if everyone understands you correctly, and misunderstanding and miscommunication will be avoided.

But even more important, a discussion will create better solutions, because there is shared knowledge involved. With a whole team, you'll be able to check if there are any gaps, if things can be done differently or more efficient. In the end, you'll be able to optimize your user stories and your solutions.

2. Try out different story formats

What is the best format for writing a user story? Start with 'I suggest...' or 'I want...'? Explain the need with 'So that I can...' or 'In order to...'? 

There's much discussion going on about which format is the best one to use for your user stories. Our advice: don't be too stuck in this debate. Fact is, there is no best template and the best way to find out which template is most applicable to your solutions and team, is just to start trying out different ones.

When you are stuck to working with one story template, there's a possibility that you will make up fake stories and you fill in a template, just because you have to. Make sure that the person in question is actually a stakeholder, and that they actually want what the card says.

Trying out different formats can cause different kinds of discussions and insights, and trigger creativity in your team. In this way, a whole new perspective can be discovered. As long if the information on the card is telling the truth, a story card is a good story card if it triggers discussion, no matter what format you use.

3. Describe the behaviour change 

How can you set the value of a user story and make sure the ones with the most value are delivered first? There's often a disconnect between what the delivery team delivers, and what the business users really care about (value), resulting in deliverables, delivered in the wrong order. To help a team better understand the added value for an end user and overcome this problem, always describe the behaviour change in a user story, not just the behaviour.

What do we mean by that? If, for example, a user story just states that users should be able to import contacts, no one will have an idea what is possible now, and what the result should look like. There is no success criterion. But if you try to capture the value not just as a behaviour, but also as a change in this behaviour, (like 'being able to upload contacts faster') a discussion can be opened, and several potential solutions can be thought of.

Understanding an expected behaviour change that represents the business value (The Why) allows the team to set up a good acceptance criterion for the user story. This makes it easier to determine whether the story succeeded from a business perspective once it's delivered.

4. Describe the system change 

As the system of software represents the What in a user story, the system change represents how the system functionality will differ between now and when the story is implemented. Put in a question: What change needs the team to make in the software in order to be accepted?

Some stories are about building a new feature from scratch, but most of them are about making changes to existing features. It's important to describe this changes to clarify the scope of the story. How much work do we actually need, to get the job done, and is this doable? This will often mean that in your story the 'I want...' needs to be followed up by 'Instead of..'

Clarifying the change is useful for the refinement of a story. It reveals its complexity and tells the team if the story might be too big, or too small and if the scope is set rightly.

5. Put a best before date on specific stories

One of the most significant advantages of user stories is the flexibility of it. Giving the stakeholders the option to change priorities and adjust the scope frequently. But sometimes it happens that new user stories are added with a deadline, but because of the big amount of other stories, and the constantly changing priorities of the stakeholder, the story is snowed under. People only find out about the story, when someone rings the bell and asks about the task. And then it can already be too late. Everyone in the Scrum team has to work extra hours to finish the story in time.

This doesn't need to happen. Good advice is to put a 'best before' date on the story and separate all the stories with an expiry date from the rest of the backlog. In this way, they can be picked up at an early stage, and they can be handled at a sustainable pace. This will save you lots of last-minute fire-fighting.

*Illustrator Credits: Created by Makrovector - Freepik