Whenever an organization brings me in as an Agile coach, I ask management, “Why am I here?” Their first answer is often, “You gotta help our teams write better user stories! They are horrible!” And generally, they’re right: those teams’ user stories are horrible. Where management is often wrong, though, is about why those stories are so […]
Whenever an organization brings me in as an Agile coach, I ask management, “Why am I here?” Their first answer is often, “You gotta help our teams write better user stories! They are horrible!”
And generally, they’re right: those teams’ user stories are horrible. Where management is often wrong, though, is about why those stories are so bad. It’s not because teams are unmotivated or untrained. More often than not, the stories are bad because teams are forced to write them in situations where doing so doesn’t make any sense.
Honestly, user stories are one of the most common things people tell me they don’t like about Scrum. This is ironic because user stories have nothing to do with Scrum! They aren’t a part of the Scrum framework, and you won’t see any mention of them in any version of the Scrum Guide. The practice of writing down a product backlog item (PBI) as user stories comes from an entirely different Agile framework (Extreme Programming, or XP).
And yet, nearly every ScrumMaster and Product Owner student I’ve had over the years starts with the assumption that the behavior is required in Scrum, and every team should write ever PBI that way. I’m not sure how that notion took hold, but it’s a common anti-pattern that good coaches and trainers must un-teach teams and organizations all over.
The “card” part is a fill-in-the-blank statement along the lines of, “As [some type of user], I want [some capability] so that [reason I need it].
The “conversation” part involves whoever wrote the Card talking to the team that’s going to build the thing until they reach a shared understanding of what is built, how it might be built, and the context and need for the thing.
The final part, “confirmation,” involves both parties working together to create a list of objective test conditions that would be met when the thing is done (these tests are called acceptance criteria).
If you do all three behaviors, everyone involved gets a holistic picture of a particular piece of work that’s informed by both the business and technical points of view. Good user stories are also a way to build empathy for users as real human beings in the minds of developers.
That pays off later when developers create a capability and discover a question that no one thought to discuss before. If they imagine how the user would actually react to the choice at hand, the developers are far more likely to make a good guess about what would be the most useful plan of attack.
So, that’s when user stories are helpful. But, when the people writing user stories don’t understand the “3 C’s,” they aren’t doing anyone any favors. In my experience, bad user stories aren’t just unhelpful; they actually become a detriment to Agility.
There are many ways that user stories can go wrong. One of the most common is that teams skip the “conversation” and “confirmation” steps. So, the team just writes lots and lots of cards. That’s unfortunate because the card doesn’t tell us much.
The real value of stating PBIs as user stories is found in the discussion and agreement steps. If you’re writing cards, but never having the conversations or writing acceptance criteria tests, you aren’t actually creating user stories. At best, you’re just doing what amounts to Agile Mad-Libs.
Even worse than skipping the conversation and confirmation, I see a lot of teams not even complete: ng the card’s bare-bone requirements! The only elements of the ‘card’ part of a user story are: who it’s for (a type of user), what they want (the feature they’re asking for), and why they want it (a justifiable business reason).
All three elements are important, but the ‘why’ is the most important. If we don’t understand the ‘why,’ how do we even know that we should spend time building this thing, let alone when in comparison to everything else we’ve asked for? And yet, weirdly, the ‘why’ is also the thing most often left off the card.
Sometimes that’s because no one on the team knows the answer to ‘why,’ and their Product Owner can’t (or won’t) do the work of finding out. Other times teams feel like knowing the ‘why’ is a waste of time. “We have to do it anyway, so who cares?” Even in situations where everything is supposedly required, knowing the ‘why’ still matters because it helps teams make better guesses when they’re building the thing and discover a question that no one considered during backlog refinement.
One more reason I see teams leave off the ‘why’ is because filling in seems silly, redundant, or too obvious to bother. When that’s happening, it’s usually because the team is being forced to write user stories to describe situations that have nothing to do with actual users.
You can know this is the case if you come across a PBI that reads something like, “As a server…I want to be patched….so that I am not un-patched.” User stories are supposed to be about helping a team of developers understand how a human being is going to interact with some piece of technology to accomplish a goal.
But if what the team needs to do next isn’t about a human/technology interaction, force-fitting the work into the user story format doesn’t make any sense. In the case I’ve just described, they’d be far better off with a PBI that simply reads “patch the server.”
Don’t forget: Scrum doesn’t care if you write PBIs as user stories anyway! Use the format when it’s helpful. Disregard it when it isn’t. There’s nothing wrong with a team’s product backlog containing some user stories and other PBIs in any other formats we like.
There are a couple of immediate steps organizations and leaders can take to get out of these anti-patterns and support healthier Scrum.
Scrum is often described as ‘easy to learn, hard to master.” That’s true! Many of the problems discussed here are easy traps to fall into as a new and inexperienced ScrumMaster.
Getting them more high-quality training like a Certified ScrumMaster (CSM) or Advanced-Certified ScrumMaster (A-CSM) course is a great way to expand their skillset and share stories with other people who’ve dealt with the same issues.
One of the most valuable services a seasoned Agile coach provides is mentoring ScrumMasters and creating a path for organizations to grow and develop their Scrum team.
Great Agile coaches can model key behaviors and teach core skills without undermining the position of your ScrumMasters and in a way that supports your teams’ ownership of their improvement.