What Big User Stories Could be Telling You

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.

Here is the story card AND all the acceptance criteria, wire frames, specs, use cases, test plans, flow diagrams, architecture...

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.

Have Conversations

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?


Like this? You’ll love Agile Eats

Subscribe to the Agilist Community Newsletter
As an agilist, you seek to find ways to improve not just how people work but also how they live. Your passion is our passion. With a subscription to the monthly Agilist Community Newsletter, you'll receive insider knowledge and insights from within our coaching community. Topics include team dynamics, Agile coaching, scaling Agile, Agile events and more.
*By entering your email address you give Accenture | SolutionsIQ permission to send you marketing emails. You may unsubscribe at any time by clicking the unsubscribe link located at the bottom of any email. View our Privacy Policy