I presented at a local professional group the other evening. I was discussing Acceptance Test-Driven Development (ATDD), but started the session with an overview of User Stories. From my perspective, the notion of User Stories was introduced with Extreme Programming as early as 2001. So they’ve been in use for 10+ years. Mike Cohn wrote his wonderful book, User Stories Applied in 2004. So again, we’re approaching 10 years of solid information on the User Story as an agile requirement artifact.
My assumption is that most folks nowadays understand User Stories, particularly in agile contexts. But what I found in my meeting is that folks are still struggling with the essence of a User Story. In fact, some of the questions and level of understandings shocked me. But then when I thought about it, most if not all of the misunderstanding surrounds using user stories, but treating them like traditional requirements. So that experienced inspired me to write this article.
In a small way, I hope it advances the state of understanding surrounding the proper use of User Stories. So here are ten indicators that you might not be looking at your stories the right way:
#1) Writing a complete story all at once – trying to estimate and get it “right” the first time
Stories evolve as they move closer to sprint execution and as they can decomposed and further refined. I consider a good heuristic that a team should “visit” each story (and its offspring) about 3-4 times before they make it into a Sprint or iteration. This would include grooming meetings and also discussions across the team.
I really want teams to take ownership of their backlogs in real-time—thinking about upcoming stories, themes, their interrelationships, and design & testing strategies. Having this occur on a daily basis creates the emergent nature of agile requirements, design, and planning.
#2) If the Product Owner asks for something not articulated on the story, you split the story and make them wait for the “additional scope”
The expectation here is that once the story enters a Sprint, there is no “scope creep” allowed. That everything needed up-front definition. If the Product Owner forgot something or wants to react to some implemented functionality, tough. They get exactly what they asked for and changes get deferred to a new story in the next Sprint.
I disagree. User Stories are intentionally ambiguous; intentionally incomplete. I use the heuristic that stories should enter the Sprint at 70% clarity and exit the Sprint at 100% clarity. The point of the 70% is that there should be ambiguity – so things are discussed, clarified and determined during the Sprint. The requirement emerges based on conversations. This should not be penalized or deferred; instead it’s the “way of things” in agile requirements.
#3) Allowing stories with very minimal or trivial Acceptance Tests to enter your Sprints
One of the more important parts of the User Story is actually on the back of the card—it’s the Acceptance Tests or Acceptance Criteria. Establishing these conditions for acceptance early on help focus the team on the purpose and important bits in a story. The help the developers design for what the customer values. They help the testers ensure the stories’ functionality meets expectations. They help the Product Owner verify acceptance, Done-ness and then move on. They speak to functional and non-functional requirements.
A bad example of a set of acceptance tests would be having one that says: “the story is accepted when the Product Owner signs off on the story”. You can’t imagine how often I see variations of these singular acceptance criteria. I have a heuristic that says a story should have a minimum of 5 acceptance criteria and at least one of them should be non-functional. If it’s a technical story, I look for most of the acceptance tests to be non-functional.
#4) Writing ALL stories with the [As a – I want – So that] format, even if it takes an hour or more to do so
Anything that you take prescriptively and do it “just because” we’re supposed to is probably a bad idea. Context matters in software teams—especially in agile teams. The standard format for writing User Stories is incredibly useful. In fact, I normally want to see teams leveraging the outer clauses of persona and business why, simply because they add so much value and nuance to the story (and the discussions).
However, I’ve seen teams often succumb to the tyranny of the story and feel compelled to write all of their stories in this format, even when they don’t truly fit. For example, I don’t know if technical stories truly fit this format. Sometimes all I want for a technical story is a definition and then strong emphasis on the acceptance tests (or how we’ll know when the story is complete). And that seems to be “good enough”.
At the end of the day, the story needs to have “words” that have meaning for the team to interpret, estimate, and execute towards delivering what the customer needs. It’s as simple as that!
#5) Believing User Stories are only for functional work (features, customer facing functionality) and not for anything else
There’s an illness in User Story writing that I want to cure. It goes by many names, but most popularly it’s called feature-itis. It’s an insidious disease that creeps up on you. The most significant symptom is backlogs that contain only feature-centric User Stories. There are no others to be found. No stories focused on infrastructure, technical debt, bug fixing, test automation, refactoring, design, research spikes, nothing.
While the customers LOVE this disease, it ultimately does them a disservice. It creates narrowly focused products that are typically very fragile. The investment in quality in all dimensions simply isn’t there. Here’s a heuristic for your stories, all work should be crafted in stories and it should always be balanced beyond—just features. If you lack discipline, perhaps use the 80:20 rule to help; 80 percent features and 20 percent internal investment.
#6) Having a goal to get as many stories done as possible within each Sprint; so heads-down get to work
What should be the goal of each Sprint? Story count, points produced, meeting the Sprint Goal? All of these are primary targets. In my workshop, the gentleman used this example. He said what if:
The product owner changed their mind during the sprint. When they thought they wanted a blue background, but in reality then asked for green. Or asked for green, when they hadn’t specified it in the first place?
His suggestion or response was to split the story. Deliver what was clearly defined and then rework the additional story later. That delivering the story was the primary goal. I.e. meeting the plan or gaining the points.
I had to disagree with him. I didn’t look at this event as a ‘fault’. I looked at it as the normal way of things as the story requirements emerged. The answer should be: listen to the customer, change it to green, and deliver the story. From my perspective, the customer “drives” in agile teams. And we should primarily measure ourselves by delivering customer value.
#7) Feeling that stories have to be complete (100% understood, written, explained) before they enter a Sprint for execution
Teams are afraid to say “I don’t know” and “We need to do some additional research, prototyping, and experimentation to more fully understand this story and how to decompose it”. Instead, they write based on assumptions. The focus is on filling in the template and going through the motions to get a complete story. Very often this takes an incredible amount of time and the team “drops into” design discussions.
What’s insidious about this is it gives the team a false sense of security. As in – they now know everything about the story and the rest is simply “implementation details”. But that was never true in Waterfall requirements and its certainly not true here. Remember the 70% clarity heuristic from #2.
#8) Teams “hold onto” stories until the very end of a Sprint, demo them, and receive feedback on the acceptance of the stories
This reinforces that view of a complete story that is developed – then tested – then demonstrated – then accepted serially through the sprint, which is probably not the best strategy. I much prefer to be demoing and interacting around stories all along their evolution within the Sprint.
In fact, there is the notion of a “Triad” in User Story collaboration; the three players being the Developer(s), Tester(s), and the Product Owner / Customer(s) all collaborating around the story. Questions are raised, clarifications are made, and the stories evolve. Only upon exit of the Sprint is the story at 100% clarity.
#9) The Product Owners must write the stories until the team “accepts” them as well-defined
I’ve seen this pattern over and over within many less experienced agile teams. Since the Product Owner ‘owns’ the backlog, then it’s their responsibility and theirs alone to write all of the stories. And beyond that, their work isn’t “done” until the team accepts the story as meeting their vision on completeness and clarity.
I say hogwash to this! Yes, the Product Owner is the final arbiter of the backlog. However, the WHOLE TEAM needs to contribute to the backlog. And the team is not some gating factor for “perfect stories”. That’s simply a Waterfall requirements mindset seeping back into the team’s behavior. Instead, everyone is responsible for getting their stories ready for execution and delivery.
#10) Thinking that estimates are only good for planning purposes
One of the best ways to move forward in understanding and decomposing a User Story it to throw an estimate via planning poker. Do it as soon as you can. Then have that wonderful discussion around the team as to what they’re thinking surrounding the estimates. Teams too often debate the nuance of a story that’s too large or complex for far too long. I like to estimate as quickly and as often as possible. It usually leads to insights at what to do with the story—break it down, run a research spike, let it alone, have some off-line discussions, etc.
Always remember, the most important ‘C’ in the 3-‘C’s of User Stories is the “conversation”. That’s the same goal for planning poker; less about the estimates and much more about the conversation(s).
Wrapping Up
I think the primary misunderstanding surrounding User Stories is that they evolve towards clarity; that you have the freedom to NOT define everything in advance, but to explore the requirements. The requirements, understanding, design, coding, testing, integration, defect repairs, and maturity of each story EMERGE over time. In other words, we’re lean in our thinking leading to just enough, just-in-time definition and delivery.
Now if we can only leave those ingrained Waterfall requirement behaviors behind us!
Stay agile my friends,
Bob.