How to Write an Effective User Story

One
way user stories can be viewed is as a conversation between developers and the
product owner. These conversations are imperative in ensuring that developers
know exactly what product they are developing and usually determine whether the
user stories in a project are good. For teams with bad user stories, the acronym
**INVEST** highlights the qualities each user story should possess, helping them
implement necessary changes. INVEST stands for

### **I**ndependent

Independence
is a significant characteristic of user stories. A straightforward way to think
of independence is to think of “order independent,” meaning stories can be
worked on in any order. This is important because it allows the team to
independently value and prioritize every story.

### **N**egotiable

Unlike
traditional requirements specifications, user stories should not be rigid rules
of direction. Rather, user stories should encourage negotiation between the
Product Owner and the development team to find what best suits the customer. User
stories should not focus on how a requirement will be implemented, but on
whether it is a feature the customer desires. The goal of meeting the customer’s
needs by determining what they want should not be clouded by the temptation to
detail how those needs will be met. The technical implementation should be
decided by the developers.

### **V**aluable

As
mentioned previously, highlighting customer value is a key part of a good user
story. Without knowing what the customer values, it is impossible to prioritize
the backlog and complete the user stories. Project owners that come from a
traditional project management background will likely struggle with this part
because they will view the

### **E**stimable

If
a user story is not easily estimated, it is likely that it is too big or
defined unclearly. This will make it difficult for the team to determine the
complexity of the work and how much effort it will require. A story being
estimable is partly a function of it being negotiable because it’s difficult to
negotiate a story you don’t understand. The solution to this can sometimes be
splitting the user story into smaller chunks since smaller user stories beget
clearer descriptions.

### **S**mall

How
small user stories should be often depends on the team. A good rule of thumb is
to create stories small enough so that they can be completed in a two-week
sprint. The size of a user story is closely connected with whether or not the
story is estimable. This is because the smaller the story, the easier it is for
the team to understand all the work the story requires.

### **T**estable

User
stories cannot be too subjective. In order for a story to truly be complete, it
must be testable. Team collaboration comes into play here because everyone one
must agree on what the definition of “done” is. A user story is considered
testable if everyone is in agreement that the story can be implemented in a manner
that fits this definition. The implementation should also include some kind of
user acceptance test.

Following
the INVEST criteria encourages good working habits and prevents the team from
running into bigger problems. INVESTing in good stories allows for work to be
more effective, time efficient, and increase of the overall productivity of a
team.

**Works Cited**

Birch, Travis.
“Summary of User Stories: The Three ‘C‘s and INVEST.” *Agile Advice*,
5 May 2015, www.agileadvice.com/2015/04/15/referenceinformation/summary-of-user-stories-the-three-cs-and-invest/.

Hartman, Bob.
“New to Agile? INVEST in Good User Stories.” *Agile For All*, 14 May
2009, agileforall.com/new-to-agile-invest-in-good-user-stories/.

Rose, Doug.
“Writing Effective Stories.” *Lynda.com - from LinkedIn*, 13 May
2015,
www.lynda.com/Business-Skills-tutorials/Writing-effective-stories/175074/387214-4.html.

Wake, Bill.
“INVEST in Good Stories, and SMART Tasks.” *XP123*, 17 Aug. 2003,
xp123.com/articles/invest-in-good-stories-and-smart-tasks/.