Why user stories?

User stories provide an excellent way to explain small pieces of your product clearly enough, so that everyone can understand what is behind. As the name suggests, they are related to a specific user (or so called persona) and allow the Agile team to feel empathy with the potential user, seeing the product from his/her eyes – what he/she needs as a certain product capability, why and how he/she will use it. Essentially, they are a way that supports us tell the product story from the user perspective.

User stories are also a great starting point for a discussion over functionality, priorities and business value. They provide an opportunity to engage both the whole team (not only the most experienced technical gurus) and stakeholders into deep dives and meaningful conversation that enriches everyone’s understanding about the product. This improves collaboration and decision making on future steps of functionality implementation.

How to write good user stories

The focus should be on what matters most for the user. In many cases a template is used to support capturing the most important information:

As a “type of user/persona”, I want “goal/an action” so that “reason/a value”

It is simple, but very powerful and mind changing, as it provokes a lot of “why’s”. Taking the time to think about them and validate with users is important for the quality of the product backlog.

Since the information captured in a user story is really the essence, sometimes additional clarifications on expectations might be needed. One of the best way to additionally imply on expectations is using acceptance criteria. It might clarify various boundary conditions or expected behaviours of the system, e.g. how the user will be using the functionality, what is the expected result, specific scenarios that need special handling, etc. This prevents miscommunication and wrong expectations. Clear acceptance criteria define the boundaries of the story (what is in and what is out), support testing scenarios and play role in estimations.

Be careful with acceptance criteria, however. It’s very easy to go into an extreme and start writing full-fledged functional specifications in the form of acceptance criteria. This is not really the idea. We want to keep user stories short, and only document important decisions taken in a discussion with the team. Hence, acceptance criteria shall not be extensive (that’s why we love using our user story templates – they do not allow us to go wild, and help us think what’s the most important insight to capture).

When to use

If you are starting a new project, holding a user story writing workshop is typically a great idea. It is usually held in the beginning of a project with the participation of all team members, stakeholders, Product owners and whoever can contribute positively to such an event. It is also an event where lots of user stories are produced. The collection of the newly generated user stories are the basis for the product backlog and the whole exercise is very helpful the team and stakeholders to start aligning.

Additionally, some outcomes of grooming meetings or other product-relevant events might be captured as user stories. And of course, writing user stories is one of the main tasks of the Product owner 🙂

What we find helpful

When teams are young or new to user stories, we encourage them using paper notes with a template similar to this one, so that everyone is supported in writing good user stories. Using physical notes in workshops is also very helpful – discussions have a different flavor when we can freely move stories around on the wall.

Order now

a pad of 100 user stories cards to help build your user-centric product backlog.

Shop now