Hello

Your subscription is almost coming to an end. Don’t miss out on the great content on Nation.Africa

Ready to continue your informative journey with us?

Hello

Your premium access has ended, but the best of Nation.Africa is still within reach. Renew now to unlock exclusive stories and in-depth features.

Reclaim your full access. Click below to renew.

|

How to write a user story? 4 tools to help you with it

User Stories are undoubtedly the most used tool for gathering agile requirements. Regardless of the Agile Method you use, a list of User stories is practically a prerequisite. Today they are undoubtedly of great importance for any Product Owner - but does every PO or Product Manager know how to write a user story?

A very common question surrounding user stories is: why should we write them? During the development of a product, teams need guidance on what our business needs are, and what should be built.

But this alone is insufficient for the development of the best solution possible, as it can be interpreted in many different ways by the team, impacting final delivery to the user.

More information and context is required for our developers. They need to know who they are developing each functionality for: who is my user? What are they like? What are their pain points and needs? We also need to explore why my user wants the solution in question: what do they hope to achieve with it? What are their expectations?

User stories function as a narrative about what, to whom and why each functionality should be delivered. As such, they are a driver for development.

What to consider before writing a user story

Certain techniques are recommended, such as 3W – “who, what and why” – and the 3C technique – “card, conversation and confirmation”.

Writing a user story is very simple, and involves following the model presented below, using relevant information:

  • How – author of the action (persona);
  • I want – desired functionality;
  • For – added value to the desired functionality.

When using the 3W technique, for example, we must pay attention to who our subject or user is. In other words, how the user considers themselves (persona), what they want to do, and why they want to perform the activity in question. Returning to the model presented above:

  • How (who?) – who am I building this feature for? Who is the persona identified by this story?
  • I want (what?) – what is the expected functionality? What does the persona want to accomplish?
  • For (why?) – what is the motivation for building this story? What value does the user expect?

The 3C technique, on the other hand, proceeds as follows:

  • Card – a user story should not be overly long, and should fit on a single card;
  • Conversation – the content should generate discussions among the team about what objectives you want to meet;
  • Confirmation – the user story should include acceptance criteria, thus enabling successful validation in both construction and delivery.

Certain tools and templates can be used by product professionals when writing user stories, like a free flowchart maker, which helps to develop a visual guide to the process so everyone on the team can understand it step clearly. 

Focus on the customer / end user, and use personas

The focus should always be on what your customer, or end user, wants. If for some reason you are not focused on your user, or do not even know who your user is, then your user stories will most likely add nothing to your product or project.

To write good user stories, the focus should be on the end-user customer, and not on what you think they want.

If you do not yet know your customer, then using personas will definitely help. Personas are characters that represent your client; in other words, a character that has the same characteristics and desires as your end user.

Products typically have more than one persona, which makes things easier. A good tip is to combine personas with story-mapping.

User Stories are informal and should represent business value

User Stories are informal and only serve to represent the wishes of your users and customers. To write good user stories, think of them as informal conversations, which are subject to change.

These stories must have a reason to exist. User stories are often created without considering the “why”. So make the business value of each one abundantly clear.

Some helpful tools 

Here are some points that need to be defined, and techniques that can be used to assist in the user story writing process:

1 – INVEST technique: this acronym contains the six main characteristics to be considered during the creation, definition and writing of a user story:

  • Independent – no dependencies or ties to other stories;
  • Negotiable – the story should be subject to adjustment if necessary, depending on changes of context or new team evaluations;
  • Valuable – should deliver value to the end user;
  • Estimable – has enough information for the team to understand and estimate next steps;
  • Sized – the story should be small, and generate as few uncertainties as possible, as part of an iteration;
  • Testable – it should be possible to define individual functionality tests based on the story.

2 – Acceptance criteria: These are like checklists that must be considered to ensure that each story is delivering what was requested and planned during its definition, in terms of functionality and delivering value to the user.

These criteria work as a detail concerning what should be delivered in each story, and help developers in the definition and planning of tests. There is no correct way to write these acceptance criteria - they can take the form of topics, or descriptions of possible usage scenarios.

3 – Definition of scenarios in user stories + BDD: one way of writing these acceptance criteria is through the definition of scenarios that can help to develop user stories. 

These scenarios map the potential paths of product usage, culminating in the success or failure of a given task. This helps developers to deal with unforeseen and alternative paths.

A helpful development technique here is referred to as BDD, or Behavior Driven Development

This technique lets developers describe the expected behavior for the functionality to be implemented, and validate the construction of the story based on this behavior.

The three keywords for this purpose are:

  • Given (provides context for the scenario);
  • When (specifies the action being performed);
  • Then (represents the desired outcome).

Some further descriptors can be added:

  • Given (some initial context);
  • And (some further context);
  • When (the primary action or event);
  • And (some further action or event);
  • Then (initial outcome);
  • And (further outcome).

4 – Defining tasks for user stories: the tasks that are part of user stories - i.e. the tasks required for the construction of each feature - need to be defined as well. 

These refinements take place at a developmental level, usually defined by the development team itself, and state what needs to be done in direct, technical language.

As for how these tasks should be described, there are no rules, except that they should be objective and clear, acting as a kind of implementation script.

The description of user stories should be written in an objective, agile and simple manner. The aim is to simply state the functionalities that the system will have, devoid of technical details.

Whenever it makes sense to build these stories, they will go through a refinement process with the whole team, before other important points for its development are added: acceptance criteria, test scenarios, technical details, etc.

When writing a user story, be sure to answer the three main questions, to ensure understanding and an assertive construction phase.

Concern yourself with understanding the context of the user and the business, and communicating this clearly to your team at a business level, rather than in technical terms. That is why it is so important to learn how to write a user story.


Sponsored Content