DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • Grow Your Skills With Low-Code Automation Tools
  • Opportunities for Growth: Continuous Delivery and Continuous Deployment for Testers
  • Understanding Data Compaction in 3 Minutes
  • The Role of Automation in Streamlining DevOps Processes

Trending

  • Grow Your Skills With Low-Code Automation Tools
  • Opportunities for Growth: Continuous Delivery and Continuous Deployment for Testers
  • Understanding Data Compaction in 3 Minutes
  • The Role of Automation in Streamlining DevOps Processes
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. 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.

Giulia Mantuano user avatar by
Giulia Mantuano
·
Aug. 22, 16 · Opinion
Like (4)
Save
Tweet
Share
5.20K Views

Join the DZone community and get the full member experience.

Join For Free

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 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.

User Stories core elements sketchnote

This article was first published on the Codurance blog.

agile scrum Software development User story

Published at DZone with permission of , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Grow Your Skills With Low-Code Automation Tools
  • Opportunities for Growth: Continuous Delivery and Continuous Deployment for Testers
  • Understanding Data Compaction in 3 Minutes
  • The Role of Automation in Streamlining DevOps Processes

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: