Put the end-user first with user stories.

User story workshop @ Formica

July 29, 2019 - by Jessica Verlinden

Last month, Formica organized a user story workshop for some members of our team. The audience consisted of people with different roles and backgrounds. Some were already familiar with the concept of user stories while others were totally new to the subject.

Luckily, we have our own hands-on-expert among us. Frederik Vannieuwenhuyse started the workshop with an interesting task. ‘Write your question regarding the topic down and make a user story about why you are here.’ It rained post-its with questions such as: ‘what is a user story’, ‘what is the difference between a use case and a user story? ‘how do you formulate a good user story?’ ‘Which information does it have to contain?’ It was a good basis to start off the workshop.

What is a user story?

‘As a reader of this blog, I want to learn more about user stories so I can make my own user stories in the future.’

This would be the user story I wrote before creating this post. User stories can be defined as a short description of features from an end user’s perspective. It’s all about the value it creates for the user. They are written in a template, with the following construction ‘as a user, I want to.., so…”. You identify the end-user, what he needs and why he needs it.  So user stories can't be written at random. To have an answer to the "who, what and why?", you have to start from a clear vision and analysis of the solution.

In an agile development context, they are used to compose and prioritize a backlog. Each sprint, the team selects the user stories with the highest priorities to work on in that specific sprint. It’s important to note that a backlog is not a static list of user stories. After each sprint, the backlog needs to be re-evaluated and if needed, re-prioritized.

What is a good user story?

It sounds cliché, but there is no clear definition of a good user story. Each team is different, each project is different and each sprint is different. Nevertheless, there are some things you should take into consideration when writing user stories.

The most important thing is the balance between not enough detail and too much detail in user stories. It is a thin line and that’s the magic in user stories: they need to contain just enough information to fully understand the value the feature has to deliver. User stories that are too ‘big’ need to be split into smaller user stories with enough detail to be used in sprints.

Next, to that, a user story consists of 3 components: 

• Card: The physical component of the user story with the here-fore mentioned template.
• Conversation: This represents the conversations with the team and users regarding the subject of the user story. Without a good conversation, there is no good user story. And it doesn’t stop there. You need to keep the conversation going and adjust the user story if needed.
• Confirmation: In this C, it’s all about acceptance criteria. They define when your user story can be considered done and are the basis of testing. Product owners, analysts, and stakeholders at the customers’ side are the usual suspects for defining these criteria.

Throughout the whole process, it’s important that there is enough alignment and trust within the team. At Formica, we believe that writing good user stories contributes to the overall quality of our solutions and projects. Investing in the teams’ knowledge and experience is key to keeping our quality standards high!