Here is my new post of the Agile series. Today, I would like to tell you about my experience on how to write User Stories and how to use them in a real project.
What is a User Story?
A User Story represents a small piece of business value that the Agile team should deliver each Sprint. It is defined incrementally in three stages:
- The brief description of the need
- The conversations that happen during Backlog grooming and Sprint planning to clarify the details
- The criteria that confirm the User Story is ok
Which is the best way to have a good
User Story ?
User Stories should meet requirements below as defined by Bill Wake’s INVEST acronym – https://en.wikipedia.org/wiki/INVEST_(mnemonic):
|I||Independent||The User Story is independent and atomic|
|N||Negotiable||The User Story can always be changed|
|V||Valuable||The User Story must deliver value to the Stakeholders involved in the initiative|
|E||Estimable||The Agile team must always estimate the size of every User Story in the Product Backlog|
|S||Small||The User Story should be as small as possible. Otherwise, it is impossible to plan it with a good level of certainty|
|T||Testable||The User Story should contain all necessary information to make tests possible|
How do I write User Stories?
User Stories typically follow this simple template:
As a <type of user>, I want <some goal> so that <some reason>.
- As a Consumer, I want shopping cart functionality to easily purchase items online;
- As an Executive, I want to generate a report to understand which departments need to improve their productivity.
Most of all, they should describe the features and the benefits from the perspective of the person, or the system, who desires the new capabilities.
In addition, it may be useful to create aggregate roles (such as the consumer) and specialized roles (such as the frequent shopper).
How to detail a User Story?
Enrich User Stories in two ways:
- Separate the User Story into multiple and smaller pieces;
- Add “conditions of satisfaction”.
Especially relevant, split large requirements (Epics) into smaller User Stories and start refining them iteratively. User stories with higher priority should be considered first.
Finally, add the “conditions of satisfaction” as a simple high-level acceptance test. They will be true after the User Story is complete.
When should I write User Stories?
The Agile team writes User Stories throughout the project, at any time. In theory, everyone participates in creating the Product Backlog that fully describes the features of the Product or Service.
Where do I have to trace User Stories and technical details?
At the beginning, User Stories were written on index cards or sticky notes (some people still use this method). They were arranged on walls or tables to facilitate planning and discussion. Now, you can count on SaaS tools to organize and manage User Stories and one of the most famous is Jira.
For each User Story, you can track additional sub-tasks in order to specify technical details. Before closing a User Story you must complete all the sub-tasks. Jira provides a really user-friendly interface to track and manage sub-tasks.
Agile Key Take Away for a consultant
There are huge differences between the theory and the reality, especially if you adopt the Agile approach as a Consultant. Please, keep in mind these hints when you write the User Stories in a real project:
- Nobody will write User Stories for you. All parties expect the Consultant to translate requirements into User Stories. You will act as a Product Owner, even if you are not. Please, consider it takes a lot of time since User Stories will change frequently;
- Write stakeholders who request a User Story. Sooner or later, you will have to justify why you have developed that specific User Story. I guarantee you;
- Agree with the customer the value of Story Points. Keep it simple (e.g. 1 Story Point = 1 Man/Day);
- Put as many details as you can. They will make your life simpler when you start the development phase. They will help you during the Sprint Review with the Customer as well;
- Always ask for formal approval before start developing. You can use PM tools like Jira to share user stories or simple worksheets like excel. In any case, ask for a formal approval;
- I strongly suggest you to use a Tool to keep the User Stories available to every actor involved. Consider to buy one which permits you to put comments and attachments to the User Story. Moreover, you also need to know who has modified the User Story and when.
Finally, I believe that many Clients (at least the ones I have met until now) are not ready to adopt Agile yet. It seems to be just a way to shorten and reduce project costs so far. Anyway, I believe in the value of this approach and, soon or later, it will be used in the proper way.
Support us with a small donation:
- LTC Address: La5f6W1rPr5VHFGCrCmPJ3sSa2AiwKZJbU
- BTC Address: 1FG1j42MUze8jiW7JbgNaUMZxZeu7M1b4f
- Ripple Address: rPVMhWBsfF9iMXYj3aAzJVkPDTFNSyWdKy Tag: 562614972
- ETH Address: 0x0940958167ca9cbd6409999957a011be7907d904