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 –

Letter Meaning Description
 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:

  1. 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;
  2. 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;
  3. Agree with the customer the value of Story Points. Keep it simple (e.g. 1 Story Point = 1 Man/Day);
  4. 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;
  5. 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;
  6. 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
(Visited 571 times, 1 visits today)
Cristiano Sacco
Cristiano Sacco

Manager with experience in Waterfall and Agile project methodologies.

Project manager with experience in different type of CRM technologies (Oracle-Siebel /

Solution architect engaged in several international CRM assessments and capability reviews.

Senior CRM application consultant, with extensive international experience working on large client projects with multi-cultural teams.


  1. “1 Story Point = 1 Man/Day”? Surely that entirely misses the point of story point estimating! Just use days!

  2. Hi Steve,

    I know it is not the best approach, but at least it can be understood by Clients. I’m still trying to figure out how to explain them the meaning of Story Points. Any suggestions would be appreciated


  3. It is still an open question whether Clients are not ready to adopt agile or Consultants haven’t find the way to deliver it properly yet 🙂

    Very interesting post!!!!

Leave a Comment