Three Common Misconceptions About User Stories

User Sto­ries are maybe the best known con­cept from agile soft­ware devel­op­ment. Unfor­tu­nate­ly it is also one of the most mis­un­der­stood con­cepts. Let’s clear up the three most com­mon mis­con­cep­tions: User Sto­ries are not part of Scrum, they are not tiny spec­i­fi­ca­tions and it is not the prod­uct own­er writ­ing them.

User Stories Are Part of Scrum

Although prod­uct back­logs of Scrum Teams often con­tain user sto­ries and tools like JIRA call the items in the back­log user sto­ries, the Scrum Guide itself does not men­tion the term user sto­ry at all. Instead, it men­tions only prod­uct back­log items as a gener­ic term for fea­tures, func­tions, require­ments, enhance­ments, and fixes.

In fact, the con­cept of a User Sto­ry orig­i­nates from Extreme Pro­gram­ming (XP), an agile devel­op­ment mod­el that was devel­oped by Kent Beck, Ward Cun­ning­ham and Ron Jef­fries dur­ing the C3 project at Chrysler between 1995 and 2000.

User Stories Are Specifications

Par­tic­u­lar­ly in organ­i­sa­tions that have been accus­tomed to plan-dri­ven work for decades, this pat­tern is fre­quent­ly observed. There are cus­tomers who want some­thing and devel­op­ers who are sup­posed to deliv­er some­thing. To make the one under­stand the oth­er, there used to be heavy con­cepts and today there are tiny user sto­ries. What stays is this harm­ful cus­tomer-ven­dor anti-pat­tern.

User sto­ries do not have that name with­out rea­son. A sto­ry is some­thing you tell each oth­er and some­thing that you talk about. A user sto­ry is an invi­ta­tion to a con­ver­sa­tion between user and devel­op­er and not a spec­i­fi­ca­tion. The find­ings of this con­ver­sa­tion are cer­tain­ly cap­tured, but this doc­u­men­ta­tion is not the story.

Ron Jef­fries there­fore pro­pos­es the three Cs for­mu­la for good user sto­ries: Card, Con­ver­sa­tion and Con­fir­ma­tion. Card means on the one hand that a sto­ry should have a phys­i­cal and tan­gi­ble rep­re­sen­ta­tion in the form of a post-it or index card. On the oth­er hand, the lim­it­ed space on such a piece of paper nec­es­sar­i­ly results in brevi­ty and thus incom­plete­ness. This card is only the begin­ning of a con­ver­sa­tion. If a com­mon under­stand­ing has been achieved through the con­ver­sa­tion, this can be for­mal­ly record­ed in the form of accep­tance cri­te­ria (con­fir­ma­tion), which then serve as basis for a test-dri­ven development.

The Product Owner Writes the User Stories

This mis­con­cep­tion is often found in com­bi­na­tion with the pre­vi­ous one. The cus­tomer-ven­dor anti-pat­tern tempts to think in terms of clear respon­si­bil­i­ties and han­dovers. The devel­op­ment team is respon­si­ble for the devel­op­ment and there­fore expects a com­pre­hen­sive spec­i­fi­ca­tion as a user sto­ry, which “obvi­ous­ly” has to be pro­vid­ed by the prod­uct own­er as rep­re­sen­ta­tive of the users. As he can­not do this alone due to the abun­dance of sto­ries, this often results in entire spec­i­fi­ca­tion teams writ­ing sto­ries for the devel­op­ment teams.

A user sto­ry is a promise for a conversation.

Alis­tair Cockburn

Who writes the sto­ry is irrel­e­vant if you see your­self as one prod­uct devel­op­ment team, i.e., if you have aban­doned the divi­sive cus­tomer-ven­dor dog­ma. Ulti­mate­ly, it’s not about the user sto­ry as an arti­fact and the ques­tion of who is respon­si­ble for it, but about users and devel­op­ers under­stand­ing each oth­er. And to that end, it helps a lot to talk to each other.