Somehow an agile myth has arisen that user stories are the one true way for an agile team to capture needs. I have the seen crazy inappropriate application 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 declaration “working software over comprehensive documentation”. User stories are certainly one 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 we 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 text book writers – was a team of 7 plus or minus two, who worked directly with a stake holder (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 stake holder who collaborated with the team to create the user stories.
Over the last fifteen years we have stretched agile thinking from those small text book customer facing teams to large programs with hundreds (even thousands) across a multitude of challenging domains (embedded systems, big data, etc). Our direct stake holder (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 mis-use. Mis-use 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 story 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 re-enforced 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 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 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 mis-use 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 text book perfect user stories. But the original problems have not disappeared because 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, that 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 on what needs to get done between a team and the product owner. Pretty forms do not replace the function of creating understanding.
A final mis-use 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 dis-empowering to turn a development team into a mere group of agile coders.
This blog is no 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 mis-use 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 captures 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.