User stories, more than just a functional definition

In the course of an agile project, we make a strong commitment to the need for the team to be able to focus on a goal of small value (or rather, assumable by the team).

This allows the team to insulate themselves from the often unattainable complexity of the complete product, and focus on providing a truly useful MPV (Minimum Viable Product) for the organization.

To reach this goal of primary work in agility, there is the concept of user story. The user story provides a powerful yet extremely simple tool to negotiate a specific need with stakeholders.

If you need a reminder of the keys to the Agile methodology, here is an article about it.

CCC. Card. Conversation. Confirmation

User stories follow a very simple principle proposed by
Ron Jeffries
(Essential XP: Card, Conversation, Confirmation (ronjeffries.com)) in 2001. And that, it must be said, is a good practice initially designed for another well-known agile framework: XP

Ron Jeffries establishes the principle where user stories should be CCC:

• Card: The user story must be able to be defined on a small card. This allows all parties to foster the ever-desirable capacity for synthesis, while allowing us to focus on what is really important. The need should be easily explained in a few lines. If this is not possible, perhaps we are trying to explain an overly complex need that should be divided.
• Conversation: What is written in the story is not the product of the solo work of a technician, a Product Owner or a user. It must be the product of a valuable conversation between all stakeholders. A conversation of value means, among other things, having the active participation of the right people to try to ensure the correct understanding of the need and its feasibility. This involves both technicians and stakeholders. And let’s remember that stakeholders are not just users.
• Confirmation: Usually, knowing in detail the need is not a guarantee that it will finally be built with the expected quality. We must include a description of how we consider that what is finally built provides the value we seek. This is known as acceptance criteria. And this work is the responsibility of the business (not the technicians). It is not enough to explain the need in detail. We must also include a description of how we consider that what is finally built provides the value we seek.

As you can see, the definition of a User Story has its structure and following it will make it easier for all interlocutors and project participants to understand it. And you may wonder, how is it written? Nothing could be easier! In a generic way and to make things easier, we can follow the following pattern:

Definition of Ready

From the last aspect of this simple principle (confirmation), we will probably be aware of a great truth in complex projects:

It’s not enough to understand the need to build a solution

Surely, to be really efficient and provide an increase in value with quality, we need to have coverage of other necessary aspects. And here appears the concept of DoR – Definition of Ready. The Definition of Ready can be understood as a agreement in the Scrum Team, where the team defines the informational elements or conditions that a user story must contain for the team to consider constructing it. And it is clear that a description of the need is not enough.

These elements are probably dependent on the type of project or the complexity of the organization itself. But we can often determine some conditions common to most projects. Some examples:

1. The need must be described in an understandable and sufficient way.
2. The technical team must have studied this need. Informatively, complementing this description of the need and, if necessary, having had a Refinement with the user or the Product Owner to ensure understanding.
3. The Product Owner should have prioritized the user story so that the team can consider it a construction priority for the next Sprint.
4. The user, or failing that, the Product Owner, must have included in the user story the acceptance criteria, which are the elements that make up the principle of confirmation.

If the story is “ready” in terms of the presence of all these elements and others that you may consider necessary, there is only one very important action for the optimal and efficient functioning of the equipment, which is the estimation in effort of the user stories. With this activity the technical team determines the weight of the story in the variable of complexity. And this helps when determining the capacity or workload of the team in each Sprint.

Do you want more information? Check out our services and let us advise you on everything related to an effective Agile transformation. Or if you wish, we can offer you an Agile consultancy at no cost to help you in the transformation of your company.