Improve team's communication with User Stories

The challenge of Software development is about building a product which fulfills both business and users' expectations.

The focus for each role within an Agile team is different: Project Managers want to see progress and want a quality product that is delivered on time and gives value for money; Product Managers want flexibility; Testers want to measure; Developers want to write outstanding and sustainable code; Users are looking for a product which helps accomplish their tasks. How is it possible to find an agreement between all of these needs and build a product which could be a good compromise between building the right thing, building the thing right and building it in time?

In order to build a shared understanding of the product vision, goals and values it is necessary to have every team member involved in the process (real users included!). User Stories are a tool that helps accomplish that: they improve communication within teams and stakeholders and reduce the risk of misinterpreting product development requirements.

What is a User Story?

A User Story is a short sentence written from the user’s perspective which describes a valuable functionality our software or system will have.

A User Story is made by 3 elements:

• Card
• Conversation
• Confirmation

The Card is the written description of the feature to implement. It must be short, one or two sentences maximum, because it acts as a reminder to discuss the feature during the Conversation phase.

The Conversation is the most important element of a User Story. To avoid misinterpretation the Customer Team (Product Manager, Project Manager, Tester, Interaction Designer, Users) and the Developers Team start a discussion around the description to identify its details and ensure that the developer will build the right solution meeting the needs of the user.

The Confirmation is the criteria for when a story can be considered "DONE". The criteria may be written as acceptance tests.

A User Story is always written from the perspective of the user. Common description formats that can help teams new to Agile practices as SCRUM are:

As a user role

I want, need, can, etc goal

So that reason

Or

In order to reason

As a user role

I want, need, can, etc goal

These formats help to keep the focus on asking the right questions, reducing the risk of getting into technical details.

Who writes User Stories?

Everyone is involved in the creation of user stories: customers, users and developers. The stories go into the Product Backlog and the Product Owner has the responsibility of deciding which one to keep and which one won’t be implemented.

What makes a good User Story?

The elements of a good User Story can be summarised with the acronym INVEST:

• Independent
• Negotiable
• Valuable to users and customers
• Estimatable
• Small
• Testable

User Stories should be INDEPENDENT of one another to avoid prioritisation and planning issues. An independent story can be implemented at any time or removed from the product backlog without having a negative impact on the other stories.

Stories are not requirements written in stone; stories are NEGOTIABLE. During the conversation phase, the Customer Team and the Development Team discuss the details and requirements needed to implement the story.

A Story must be VALUABLE to the user (who will use the product) or the customer (who will buy the product). This is the most important part of a User Story. The best way to achieve this is to have both real users and customers in the Customer Team so that they can write stories by themselves.

A Story must be ESTIMATABLE. Developers must be able to understand how much time it will take to complete a story. There are few reasons why sometimes it is not possible to estimate a story:

• the goal and the description is not clear to them
• they lack in technical knowledge
• the story is too big

A SMALL story is easier to understand, estimate and break into tasks. A big story that can be broken into multiple smaller stories is called Epic.

A story is TESTABLE. Only if it succeeds in passing acceptance tests a story can be considered complete and the customer can have a new piece of working software.

Conclusion

User Stories have been designed to build shared understanding between the Customer Team and the Developer Team. They are conversations that lead to an agreement on what to build and their format helps teams to keep the focus on delivering features valuable to business and users. That’s why they fit really well in an iterative and incremental development process.

I would like to share with you my sketchnote about the topic. I hope it can help you remember the core elements of User Stories and the reason why they are so important.

Feel free to send your queries and comments to GiuliaMantuano.