Improve Your Team's Communication With User Stories
Improve Your Team's Communication With User Stories
For most development teams these days, user stories are old hat and part of their development process. For some, this isn't the case. Regardless, knowing how to effectively use them is a good idea. Read on to find out more.
Join the DZone community and get the full member experience.
Join For FreeDownload the whitepaper on Product Centric Agile Delivery. Brought to you in partnership with Jile.
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 roleI want, need, can, etc
goalSo that
reason...or...
In order to
reasonAs a
user roleI 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 summarized with the acronym INVEST:
- Independent
- Negotiable
- Valuable to users and customers
- Estimatable
- Small
- Testable
User Stories should be INDEPENDENT of one another to avoid prioritization 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.
This article was first published on the Codurance blog.
Download the whitepaper on Five dimensions of Scaling Agile in Large Enterprises. Brought to you in partnership with Jile.
Like This Article? Read More From DZone
Published at DZone with permission of Giulia Mantuano , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}