Originally Published in March 2017, this was a forerunning to developing the concept of a Rock. User stories are one example of a well-formed Rock.
Somehow, an Agile myth has arisen that user stories are the one true way for an Agile team to capture needs. I have seen the crazy, inappropriate applications of user stories create resentment in Agile teams. For example:
“As a transmission control module, I need to raise the keep-alive signal to the engine control module so that the engine control module knows that I am still here.” Really?
I am tired of pedantic team members and agile coaches conflating an idealized user story format with a “good” backlog item. What I am calling the tyranny of the User Story is how many choose to ignore context and mindlessly strive to create some idealized user story as a “good” backlog item, regardless of how inappropriate this may be.
Part of why Agile works is its focus on getting something done. This is clearly expressed in the Agile Manifesto value, “working software over comprehensive documentation.” User stories are certainly a really good way to quickly create valuable working software. User stories capture a small slice of something that is valuable to a user of the system, which can be quickly delivered by an agile team. So, what’s not to like about user stories? How can these beautifully intentioned and simple artifacts have evolved to impose a tyrannical rule on a team or even an entire program?
First, a little background: 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 7 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 that stakeholder who collaborated with the team to create the user stories.
Over the last fifteen years, we have stretched agile thinking from those small textbook customer-facing teams to large programs with hundreds (even thousands) across a multitude of challenging domains (embedded systems, big data, etc). Our direct stakeholder (e.g., product owner) is but one step in a long chain of activities that creates value for the organization. Do we really still believe the “As a <persona> I want <something> so that <why>” should be the preferred approach for expressing a valuable need?
As with much in agile, the problems are not with the use of specific artifacts or practices; rather, it is with their misuse. Misuse arises when we ignore context and assume that if we have a hammer, then everything is a nail. A major user story misuse is the assumption that user stories are the one true agile way to capture needs. Let’s be clear: while user stories are a great way to capture user needs, they are only one type of backlog item. However, many of us intimately link user stories and agile because when we were learning Scrum, we remember how our instructor dutifully took us through user story writing. So, of course, we automatically associated “user stories” with “agile requirements”. This belief is dutifully reinforced by pedantic coaches and team members who derisively call out team members who do not follow the one true form, declaring them as “not agile” heretics.
However, search the Scrum Guide, and you will not find a single reference to user stories because user stories are not Scrum artifacts. 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 certainly satisfy this definition, and while they are a good way to satisfy this definition, they are not the only way. Unfortunately, some agile methodologies have bolstered the user story tyranny by defining their backlog items as “stories.” This unfortunate naming choice serves to reinforce the belief that only user stories can be used to capture needs. While user stories are certainly good backlog items, good backlog items are not necessarily user stories.
Another misuse of user stories is conflating the idealized user story format with the purpose of a user story. A root cause of many agile team issues is poorly understood requirements, and a typical Pavlovian response to this issue is declaring the team must write better user stories. The thinking is if we focus on the user story format, then we will have a better understanding of the requirements. So begins the intensive user story coaching for the team. Coaches and trainers love this because it creates the illusion of making a useful intervention. The team can now write textbook-perfect user stories. However, the original problems have not disappeared because the form is not a proxy for function.
The function of the user story is to create alignment and understanding between those who want something and those who will deliver it. I do not care how well-written a user story is. If there is no story in the user story, there is no conversation between the product owner and the team. Then, the story is no better than the traditional prescriptive requirements simply thrown over the fence to the team. The user story is a wonderful tool for creating alignment and understanding of what needs to get done between a team and the product owner. Pretty forms do not replace the function of creating understanding.
A final misuse of user stories is how user stories can de-legitimize any work other than coding that directly creates “working software” by the team. For any sophisticated system, the activities associated with ideation and developing user stories are outsourced to some “magical” process beyond the product owner so the team can have the luxury of pretending they are truly agile, hopefully delivering working software every sprint. It is completely disempowering to turn a development team into a mere group of agile coders.
This blog is not an indictment of user stories, and if that is the message you are taking away from this, then I apologize for not properly expressing my message. This blog post is about how applying user stories out of context, that is, the misuse of user stories, creates the illusion of agility while the team can fail to deliver. Agile teams work because they focus on getting something done, and the function of a user story is to capture some small sliver of value the team can get done within a short timebox. 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 – a good one, but just one form to achieve our desired function. Do not let the user story tyranny stop you from doing what makes sense in your context.