User stories are intended to be a high level description of some functionality. It is, however, common to find user stories growing into specs or large use cases that resemble whatever the organization used to do, back when they did large requirements documents. Comments like “The stories are not detailed enough to start development” or “This took much longer than expected so we should have more acceptance criteria for next time” can become common. There is a balance here that we should watch and adjust carefully. And most of the time we think the solution is more story documentation.
Why User Stories Get Big
I like user stories as an easy to understand idea for a company to start thinking about a light weight way to communicate needs, features and benefits. It is hard to describe in brief sentences all the forces that pull organizations to keep them thinking in lots of details. A few might be:
- A culture and history of Big Design Up Front that makes it hard for feature definition to happen just in time.
- A continued need for long range planning requiring estimates for work that will possibly take months before it actually starts.
- Skilled technical people who are accustomed to talking about technical details instead of the needs of the user.
- And more…
Lack of Focus
The most powerful and subtle force to cause “user stories” to grow is a continued lack of focus for the people defining features and those creating the features.
For example, if I am Product Owner of 5-12 products working with 3 teams who are all working on multiple products, I am not able to think of a feature, collaborate on it’s definition as it is built, see it created and then think about the next feature. I have to document my thinking of every feature because one hour from now I have to think about other features that also might not be built right away.
The key to being truly Agile is to finish stuff. The more inventory of ideas, features, undeployed code, etc. that we have, the less Agile we can be.
In short, Ron Jeffries, the inventor of User Stories, said that the user story should have “3Cs” of attributes: Card (small enough to fit on an index card), Conversation (is a place holder for conversation) and Confirmation (a definition of when we are done, such as acceptance criteria). Most of the symptoms prevalent when stories grow big are likely indicators that the Conversations are not taking place and people are writing stuff down in an attempt to fill the gap.
Don’t write more stuff down. Figure out why the right conversations are not happening. i.e. “Individuals and interactions over processes and tools.” That said, sometimes what we see as an over-documented abuse of the user story is a vast improvement on what the organization used to do. We have to temper our zeal with a dose of client reality as we work to get incrementally better.
Do you see user stories getting too big? If you don’t use user stories, does what you use help or hinder conversations? What is your balance between the ability to deliver vs. the need to document thinking?
Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.