User Story Traps

Feel free to add your own User Story Traps in the comments below.

Intro

This article assumes that User Stories are used with Scrum, though much of the advice can be translated to other development processes.  User Stories and Scrum are two completely independent practices.  Neither requires the other, though they are often used together.  In fact, User Stories are suggested in the Scrum Guide as a technique for representing Product Backlog Items.

The traps below are in order from most impacting to least impacting, as judged by my own knowledge of User Stories, as well as by coaching 5 development teams on the best practices of User Stories.  My intention here is to help other teams maximize their effectiveness with User Stories, by being aware of some of the User Story traps that should be avoided.

To learn how to avoid User Story Traps and maximize your User Stories practice, see more info about our User Stories Class.

Trap #1: Thinking a user story is a sentence, or a card

The most common misconception, and the most dangerous trap, is thinking that a User Story is a sentence (like “As a user…I want…”) or an index card on a Scrum board.  A sentence generally only describes the User Story description(aka User Story Title), and the card can possibly include the title and/or tests, but a User Story is more than that.  First and foremost, you must understand what a User Story truly is, and that it contains 3 very essential parts. The more modern definition below is my own, but it is based very largely on the definition of a User Story as described in Mike Cohn’s book, User Stories Applied.  Another good resource for defining a User Story is Ron Jeffries’ article:  http://xprogramming.com/articles/expcardconversationconfirmation/

A user story describes new or changed functionality that will be valuable to an external stakeholder of a system or software. User stories are composed of three aspects:

• a written description of the story used for planning and as a reminder
• conversations about the story that serve to flesh out the details of the story
• tests that convey and document details, that can be used to determine when a story is complete, and that are almost always automatable

By external stakeholder here, we mean a stakeholder external to the development team.  It could be a user in your company, an executive in your company, another development team inside or outside of your company, your Product Owner, or any other role that is not officially a member of the development team who is implementing the story.

Not understanding the definition of User Story, and not realizing that every User Story contains 3 very essential pieces, is the biggest User Story Trap of all.

Trap #2:  Everything is a Story, aka(“A story is just some code that needs to be written…”)

A widely believed misconception is that everything a development team does is a User Story.  A similar view is that a User Story is just a “High level task” on a project plan, a piece of software that nees to be developed, or some other misapplied knowledge.  A User Story is very different from either of these two descriptions.  A User Story delivers clear business value via a change in the product to a stakeholder outside of the dev team, and most often, directly to a user of the system under development. I’ve seen teams mis-use User Stories to represent the following kinds of tasks:  Setting up a staging server, Testing, Regression Testing, Time to write User Stories, Scrum ceremony meetings(even assigning Story Points to Sprint Planning Meetings!! )  These others efforts can be called anything you want to, but calling it a User Story, Technical Story, or all other manner of pseudo User Story or Scrum terms is fraught with danger that will defeat 20-80% of the benefits of using true User Stories. One of the biggest dangers is that assigning story points to these kinds of activities will totally pollute your velocity measurement.  Advice:  Scrum meetings and ceremony are tasks, and can be tracked as such on your Sprint Backlog.  Other dev type tasks that are not directly related to delivering something of value to external stakeholders or users can be called “dev items” or “dev time”.  Track these dev items totally separately from the Product Backlog, and let the dev team bring them into sprints as tasks as they so choose.  Only the dev team(remember, in Scrum, the “dev team” role does NOT include the Product Owner) can decide how much Product Backlog work can be taken on during a sprint, so when the dev team decides to prioritize these dev items, they will need to take those efforts into account when taking on Product Backlog.  Having said all of that, any development/programming/testing activity that can be directly tied to a Story should be tied to that story and estimated with that story.  Dev items are only for things that cannot be tied directly to a Story(Examples: Setting up a new test server, Upgrading your dev tools, researching dev tools or libraries, resolving technical debt, attending training — so long as none of these items can be directly tied to one or more User Story requests — sometimes they can, and then they are just considered a task for the story.).

To learn how to avoid User Story Traps and maximize your User Stories practice, see more info about our User Stories Class.

Trap #3:  Lack of clear acceptance tests

This one comes in a few flavors.  Sometimes is simply a lack of well understood acceptance tests.  Other times is comes in the form of thinking a user story is just a sentence or is just a “card” on the board.  Many people mistakenly think a user story is some sentence that begins with “As a , I want , so that…”.  Focusing too much on the “As a user…” template is a User Story trap of it’s own — see below.
Acceptance tests should be well understood by all on the team. There are numerous techniques for acceptance testing, but the key principle in all of them is that they should be created such that they can be automated. You don’t have to automate all of them, but they should most often be ‘automatable.’  Some of the more popular techniques of documenting acceptance tests at a conceptual level are “Test that…”, Given/When/Then, and Specification by Example.  Any team wanting to do User Stories well should take the time to master one, or preferably more, of these techniques.  Also, don’t forget to make strategic use of simple tables, bullets, flowcharts, and pictures when a visual conveys meaning better than text. It has been my experience that teams often focus too much on the User Story description and conversations, and very little on acceptance testing.  This is backwards, in my opinion. The focus should be mostly on acceptance testing, followed in priority by the conversations, and then last priority is the User Story description/title.

Trap #4:  Not slicing stories small enough (aka “Stories are too big”)

The high collaboration nature of User Stories requires that the conversations be such that they can be absorbed and remembered just long enough to be implemented, without the aid of comprehensive documentation.  If the User Stories are too big and/or complicated, very little will be remembered over a time period longer than a few days, and usually bugs or misunderstandings will result.  The key is to get the main acceptance tests for a User Story well understood and agreed upon, and to remember them just long enough to automate them and/or gain acceptance for the User Story from the Product Owner.  Put another way, a User Story should be small enough for one or a pair of developers to complete, from start to finish (including testing and acceptance!) in 2-5 days.  Put a third way, One of the reasons that Extreme Programming required that Story Cards(Description, conversation notes, acceptance test notes) fit on two sides of a 3 X 5 index card is because it would naturally limit the story size to something pretty small. It’s pretty challenging to split stories well, and it’s even more challenging to split them this small.  If your team’s not good at these techniques, start with a less stringent goal, like stories should take no longer than 8 days to complete, then work your way down to the more optimal size of 2-5 days, favoring the smaller side of that range.  At first, when splitting stories into 2-5 day efforts, it might seem like you’re delivering a tiny amount of functionality, but that’s ok.  As you aggregate lots and lots of these 2-5 day efforts together, by multiple team members, the system starts to take shape, and you need less and less documentation to remember User Story details.

Trap #5:  Slicing stories incorrectly

Slicing stories, like acceptance testing, is another area where there are several techniques that can be used.  The key concept in any sliced story is that the story still provides at least some very small piece of functionality that is visible to the end user or external stakeholder. Slicing a story into chunks like “create database tables” and “write order service” is fine for tasking out a story in a sprint, but these dev tasks are not stories in and of themselves if they don’t provide functionalty to the end user or external stakeholder.  There are numerous story slicing techniques documented on the web, so to avoid this trap, read up on some of them and strategically and correctly slice your stories.

To learn how to avoid User Story Traps and maximize your User Stories practice, see more info about our User Stories Class.

Trap #6:  Not adapting to your Product Owner

One of the purported concepts of User Stories is this notion that requirements are communicated verbally.  Ideally the PO role is a full time job in and of itself, and one that requires high availability to the dev team.  Any less than that availability and commitment, and the development team’s velocity is going to suffer because strong verbal communication is out the window.  (Incidentally, the failure to recognize this is one of the main reasons companies don’t realize the agile productivity payoff that they hear about in the agile community.)  PO’s, as a rule of thumb, should spend about 2/3 of their time with the dev team describing and implementing stories, and about 1/3 of their time with users and other stakeholders gathering and prioritizing stories.  Note that this leaves no time available for any other responsibilities. That’s the ideal world, but you don’t live in that world, do you?  Don’t worry, all is not lost.
In cases where the PO is not 100% time allocated to the team, your team will need to adapt.  This will probably mean more documentation(the price you pay for less verbal communication), more scheduled backlog grooming sessions, and a lower overall team velocity.  Some companies are willing to make that trade off, though I think generally it’s not very wise.
User stories, and in particular acceptance tests for those stories, will need more documentation because the developers can’t simply turn around in their chairs and ask the PO a question.  The task of doing this documentation generally falls on the PO, but not always, and the dev team needs to assist as best as possible.  So, instead of the User Story card with a few notes jotted down, you might need some pictures or simple Word Processing documents that describe the stories and acceptance tests.  My favorite tool for this purpose is a wiki.  Remember though, use the least amount of documentation that could possibly work.
In addition to more documentation, backlog grooming will need to be regularly scheduled and strictly adhered to in order to ensure that requirements are communicated well to the entire team.  A rule of thumb is to schedule 1-2 hours of backlog grooming per week.  Backlog grooming is good for all teams, but it is essential for team’s who don’t have a full time, co-located PO. Failing to adapt to your PO’s unavailability is a User Story trap, but one that can be avoided or at least mitigated.

Trap #7:  Product Owner is the bottleneck

If your team has a situation where the PO is a bottleneck for requirements understanding or User Story acceptance, your team will have a really hard time doing User Stories well. The causes for the bottleneck come in several flavors:  indecisive, inexperienced, or highly unavailable Product Owners just to name a few.  There are mitigation strategies for all of these situations, but when the “quarterback” of your User Story team is not playing well, the entire team suffers quite a lot.  It can lead a team to think that User Stories don’t work, but nothing could be farther from the truth.  The team should try to think positive and try to find a strategic solution to the impediment.  User Stories, like all development activities, require an effective Product Owner to work well, so don’t fall into the User Story trap of allowing a Product Owner to be the bottleneck.

Trap #8:  Focusing too much on the “As a user…” template

If you’ve done any material study of User Stories, you’ve undoubtedly run into the “As a , I want , so that …” template.  It’s an interesting technique that let’s you know what you’re trying to accomplish, for whom, and why, but don’t fall into the trap of focusing too much on this description of a User Story.  Any time you catch yourself spending more than 60 seconds trying to word that sentence or fit into that template, you probably have wasted time.  Instead, don’t use the template! Give your team a 30 second elevator pitch verbally(the who/what/why), and then focus much more on discussing the acceptance tests for the story.   Don’t be afraid to give your story a simple description like “Add item to cart” or “Pay with credit card”.

To learn how to avoid User Story Traps and maximize your User Stories practice, see more info about our User Stories Class.

Trap #9:  Focusing too much on the User Story Title/Description

Along the same lines as focusing too much on the User Story template, focusing too much time on wording the description (aka User Story Title) is a trap as well.  The title should be the shortest and simplest thing that could possibly work.  The only purpose of the title is for conversation among the team and stakeholders, and for distinguishing that story from other stories. It can be simple as “Add item to cart, part 1,” “Add item to cart, part 2”, or “Remove item”.  The PO should probably just give the story a 2-3 word name and unless there are very strong objections from the team, that name should remain as it is.  Many teams number their stories as well, and after discussing the story with the short title a few times, might even shorten it further in their conversation to  just “Story 103”.  Don’t get too fancy with your number scheme though, that’s a waste of time, as a simple unique number will do.   Worrying about naming stories is probably leftover baggage from a time when Use Cases were living documents.  User Stories are not living documents, and ideally, they should be torn up after they have been accepted as “done”, because the story’s acceptance tests have been automated.  As such, the title just needs to be good enough to use in conversations over a 2-3 month period, the average lifecycle of a story.

Trap #10:  Focusing too much on documentation details

This is a trap easy to fall into, especially for those who have previous skills in documenting requirements.  In past processes, highly wordy documents were the norm, as was a sort of “throw it over the wall mentality.”  In addition, those documents were expected to be a living description of the system at any given time, so painstaking care was often given to keeping the documents consistent with the functioning system.  With User Stories, a totally different frame of mind is necessary.  User Stories, as a document or artifact, only live long enough to get acceptance on the implemented story. This usually means 2-3 months, and then the User Story details themselves, can literally be trashed.  Note that, in order to “trash User Stories”, you’ll need to do a very thorough job of testing, and you’ll also probably want to do a high degree of automated testing. These automated tests will serve as the backbone of describing correct system behavior, thus supplanting the need to keep your documents up to date.

In addition to not viewing User Stories as living documents, the “throw it over the wall” mentality cannot exist in the User Story realm.  With User Stories, there is constant collaboration between the PO and the team, which is really the opposite of “throw it over the wall.”  So, having said all of that, don’t fall into the trap of obsessing on every last documentation detail, and certainly don’t attempt to keep the User Stories as a living document.  Focus instead on keeping stories small, verbally communicating a ton, and automating tests that themselves describe the correct system behavior(this is often called the “executable specification”).

To learn how to avoid User Story Traps and maximize your User Stories practice, see more info about our User Stories Class.

Trap #11:  Stories have too much ambiguity

This trap is almost always a failure of communication.  The primary person responsible for making sure requirements are communicated is the PO, but that doesn’t mean they’re out there all alone.  The entire team is responsible for communicating and optimizing their communications for success.  Sometimes a PO is inexperienced and doesn’t know how to write “actionable” requirements.  Sometimes the dev team is too passive to ask questions.  User Stories, like any other method of communicating requirements, must be well understood by the dev team and the PO.  If you need to schedule informal or even more formal meetings, do it, and don’t be afraid to do it.  At the end of any User Story discussion where a User Story is about to be started on or has already been started on, everyone in the room ought to be able to answer this question affirmatively:
“Does everyone here think that they understand roughly 90% of what needs to be understood in order to successfully deliver this story?” If anyone says no or “I’m not sure,” then the next conversation ought to be about what it will take to get those answers to change to “Yes.”

Trap #12:  Specifying too much implementation in stories

This trap generally surfaces when the Product Owner is someone who has a technical background, or on a project where the “user interface” for the product is technical (like an api, or web service).  This trap, though, is common to all requirements communication strategies (Use Cases, Prose functional requirements, etc), and the same principle of not specifying implementation is just as true with User Stories as any other requirements strategy.  No matter what technologies are involved, all references to implementation should be removed, and I find that this is possible about 99% of the time.  The User/System interaction is the boundary or behavior which should be specified.  Sometimes the “User” is another system, upstream or downstream or both — that’s ok.  Even then, you can specify the interaction between the two systems, but again, only specify the behavior at the boundaries of the system under development.  Some people say that the Product Owner /User Stories express the “what”(functionality), and the dev team determines the “how”(implementation).    In all cases where the user of the system is a human, the User Stories, and more specifically, the acceptance tests, should be written in the language of the human user, using their business domain terminology.  In cases where the user is another system, you should still strive for behavior specific language in business terms that can be understood by business  stakeholders.

Trap #13:  Not recognizing that verbal communication(conversation) is key.

Many software development teams are used to a low communication quotient.  They traditionally survived on very few meetings and very specific requirements documents.  User Stories(and processes like Scrum) take a huge leap in the other direction by encouraging tons of communication and very little documentation.  Your team will need to learn that there will be LOTS more meetings, and that these meetings will seem to last for ages at first, that is, until your team begins optimizing their communications. It’s frustrating at times for teams new to this concept, but I’ve seen the optimization happen on several teams.  A 2 week sprint planning meeting might at first take 8-10 hours, but after 3 sprints, that time might be down to 2 hours.  The same is true for User Stories.  Everyone on the team needs to get comfortable with the idea that verbal communication is the silver bullet to executing agile processes and User Stories well. Don’t let your team fall into the trap of thinking thinking that everything is the same as used to be, except now we call Use Cases “User Stories,” and now our weekly status meeting is equally replaced by a “sprint planning meeting.”  Nothing could be further from the truth, and not truly changing the team mindset is a User Story trap.

To learn how to avoid User Story Traps and maximize your User Stories practice, see more info about our User Stories Class.

Trap #14:  Trying to go mostly verbal too soon

In an ideal User Story world, a team would:

• be co-located and have informal conversations for much of their workday
• have a highly available, co-located, experienced Product Owner, who is also highly proficient in User Story best practices
• only need white boards and/or or 3 X 5 notecards with notes on them as documentation
• have almost all of their acceptance tests fully automated, and
• have low turnover of personnel

The theory is that then they will be able to deliver good quality software, extremely efficiently.    That is the vision of User Stories.  However, many teams new to User Stories, especially those that hate documentation, will often try to go “mostly verbal” too soon.  If your team lives in a world where the above ideal conditions do not exist, you’re probably going to need more documentation for your User Stories, mostly in the form acceptance tests expressed as text/prose.  Try to use the least amount of documentation that could possibly work, then inspect, experiment, and adapt. Once you can slice stories small, attempt to go mostly verbal on the smallest of stories, then work your way up to going verbal on medium sized stories(or on making it so that all stories are small!), and so on.   Trying to go highly verbal before your team has a good grasp on other User Story best practices is a trap you should try to avoid.

In Closing

Unfortunately, there aren’t a bunch of great resources for information on how to practically apply User Stories and deal with the obstacles to good User Story effectiveness.  Mike Cohn’s book from 2004 is pretty much the definitive work(on how to do it well), though there is some other information in XP books (XP is where User Stories originated) and articles.  What I’ve provided here is what I believe to be a set of gotchas to watch out for.  You may not agree with everything I say above, but I hope at least some of these traps are easier to avoid after reading this.

To learn how to avoid User Story Traps and maximize your User Stories practice, see more info about our User Stories Class.

Feel free to add your own User Story Traps in the comments below.

May the Sprint be with you. 🙂

© 2010 Charles Bradley.  All Rights Reserved.