End the User Story Tyranny

Somehow an agile myth has arisen that user stories are the only way for an agile team to capture needs. As a result, I have seen the crazy and inappropriate application of user stories create not only a lot of angst and confusion, but also a lot of resentment in agile teams. In my coaching practice, many of the issues I see with agile teams can be traced back to a low quality expression and understanding of needs. A common prescription for this is the rigid enforcement the user story format and the demand for precisely written acceptance criteria. Coaches and trainers love this because they can create the illusion of making a useful intervention. The team can now write textbook-perfect user stories. The problem is the original issues have not disappeared, because form is not a substitute for function. The team is still “agile in name” only.

Part of why Agile works is its focus on getting something done quickly. User stories are a really good way to quickly capture and create understanding about what valuable working software needs to do. User stories enable the rapid delivery of working software by capturing the desired behaviour of a small slice of the system. By delivering small slices of working software to our stakeholders we can quickly learn what the really need. So, what’s not to like about user stories? How can I assert that these beautifully intentioned and simple artifacts are imposing a tyrannical rule on a team, or even an entire program? When used appropriately, user stories are a wonderful and amazing tool. However, when we choose to disregard context and force all needs to be expressed as a user story, then they can become a tyranny imposed on the team or the program. Often the result is a frustrated team that believes agile does not work for them.

User stories were originally an XP artifact and were popularized with the publication of Mike Cohn’s “User Stories Applied” in 2004. Back in 2004, the scope of agile methodologies – at least for textbook writers – was a team of seven plus or minus two who worked directly with a stakeholder (e.g. the customer representative, or product owner). The systems they tended to build were customer-facing and had direct users. The world began and ended with the product owner or customer representative who co-wrote the user stories with the team. However, over the last 15 years we have dramatically stretched agile thinking from those small customer-facing teams to much bigger teams working on larger and more complex systems. User stories are not necessarily the most effective or appropriate tool for capturing in expressing needs in all domains.

Many of us tightly associate user stories with agile because when we were learning Scrum, our instructors dutifully took us through user story writing and judged us on our ability to express needs in the <As a> …<I want> …< So that> …format with precisely scoped acceptance criteria. But if you search the Scrum Guide you will not find a single reference to user stories because user stories are not a Scrum artifact. All Scrum declares is:

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when Done” – Scrum Guide

User stories are certainly a good way to satisfy this definition of a backlog item, but they are not the only way – and while user stories can make good backlog items, good backlog items are not necessarily user stories. Unfortunately, some agile methodologies and tools have bolstered the idea that user stories are the only true backlog item by defining their backlog items as “stories”.

This post is not an indictment of user stories. Rather it is about how dogmatically focusing on the user story format without consideration of context or understanding creates the illusion of agility – what is sometimes called cargo cult agile – while dooming the team to frustration and even failure. Agile teams work because they focus on getting something done, and the function of a user story is to create understanding about some small sliver of value the team can get done within a short timebox. Our job is to create a flow of value for our stake holders. If a user story can do that for you, then a user story is the right tool for the job. But user stories are just one “form” for performing this function. Do not let the user story tyranny stop you from doing what makes sense in your context and capturing stakeholder needs in whatever format works. After all, Mike Cohn is not going to come to your site and give you a gold star for beautifully written user stories. But your stake holders might for rapidly delivering a flow of value to them.

Put the Story Back Into User Stories

User Story – A Promise for a Conversation

User stories are a lovely manifestation of “individuals and interactions over processes and tools”. The team and the stake holder get together and have a conversation where a story about a need is told. The ensuing conversation helps create understanding and clarity. User stories facilitate collaboration, and create a shared clear understanding of what is really needed between customer representatives and development teams in a fast and economical way. Originally an artefact from eXtreme Programming (XP) user stories are now a part of most agile methodologies.

Unfortunately somewhere along our journey towards agile maturity we seem to have forgotten about the “story” part of user stories. Agile coaches love to teach the so called “3Cs” of user stories, Card, Conversation, and Confirmation and yet a common problem I have observed multiple times with many teams is that we have forgotten about the conversation. It seems the product owner writes the user stories and just drops them onto the team. There is very little of the collaborative writing and revision that fosters understanding. The promise for the conversation seems to have been broken.

This processes and tools approach to user stories is common when the product owner/customer representative is geographically separated from the team (e.g off shore development team). The lack of a conversation – the lack of interaction between individuals – now means heavyweight processes and tools are needed to communicate what could have been understood in a simple conversation. I have seen user stories where the acceptance criteria were 6 pages of psuedo code. All this did was push the cost of development up stream from the off-shore development team to the business analyst writing the user story. Worse, it dramatically slowed the decision making process and the cycle time. These are the real economic cost of trying to save money.

As agile coaches we have to share some responsibility for this. Many development problems are traceable to “poor” user stories and our typical solution as coaches is to emphasize well formatted user stories….those that meet the INVEST criteria, those written in the “As-a, I want, Such that” format popularized by Mike Cohn. We chastise those who do not write “high quality” acceptance criteria. However, high quality user stories are not a proxy for understanding. Are we failing to ask the questions, do these stories create a shared clear understanding of what the need is? Are they still a manifestation of “individuals and interactions” or have they become “processes and tools”?

As product owners, as business analysts, as developers and as coaches we need to put the story back into user story. Not break the “promise for a conversation” but embrace the individuals and interactions that co-write the user stories that creates the shared clear understanding of what the need really is. The first time a team sees a user story must not be the iteration or sprint planning meeting. For without the story, there is no user story.