Walking across a tightrope 30 feet in the air would frighten most of us, but having a safety net might make you feel safe enough to try it. The reality is you can get hurt pretty badly in a fall even with a net, so the feeling of safety is more perception than reality.
For teams happy with the perceived security provided by highly detailed, prescriptive requirements, moving to user stories will probably feel like removing that safety net…more detail is seen as more security. But when practicing Agile, making that move is essential to shortening your timelines to release, eliminating waste in your development processes, and having more assurance that what is actually developed will more closely align with business needs and wants.
What's Your Story?
So why do Agile practitioners favor user stories? A user story is a starting point for a conversation between a Product Owner and the Development Team. It's a vehicle to express the business needs to the Team, in language that a user of the application should understand. A classic user story template has the following format:
As a [user role],
I want to [accomplish a goal],
so that [reason].
Let's examine that story template a little bit. Why is it so effective? We find an answer by looking to journalism and police investigations, to the "Five W's." In those arenas, these are essential elements of gathering or telling any complete story. You likely learned them in high school composition class, too. (The documented origins go back at least 2,000 years to the Roman orator Cicero, so it's safe to say they're time-tested.) They are the questions:
- Who
- What
- When
- Where
- Why
"As a city visitor,
I want to get a list of festivals during my vacation week
so I can plan my itinerary."
Who=a city visitor, (not a resident)
What=get a list of festivals for the week they'll be in town
When=(presumably) some time before their vacation week? How much before? Good question…
Where=on their mobile device (we're building a mobile app)
Why=to plan their vacation itinerary
How=??? Yes, the "How" is missing, and that is on purpose.
The story clarifies the essential elements of the goal. Notice that the "When" answer generated a question for discussion and clarification. Notice too, that no implementation details are present…there's nothing in there about buttons, links, grids, etc. The answer to the question "How do we get there?" is left up to the development team. The Product Owner owns the 5 W's, but the development team owns the "How." And in the conversations around the user story, you also end up tapping the creative minds of the developers to help shape the requirement. That input might otherwise be missed by just relying on the one-way communication of handing them the finished requirement.
"But I want my detail!"
A car salesman can show you a brochure, review all the technical specs on a car, and tell you how great it is, but only when you test drive it do you get the real feel of whether it's right for you. I tell my teams that "at some point, you will have all the detail." That's at the end of the iteration, when the feature is delivered. Only then are all the unknowns eliminated. Both Agile and traditional requirements get you to all the detail, they just go about it in different ways. Traditional requirements are most often developed completely before development begins. Detail is arrived at by people speculating, projecting, maybe wire framing, and likely guessing at what the end state of the feature will be. The challenge there is that change is a constant, so everything that changes in the end makes the upfront effort to project the end state of what ended up changing into wasted effort. In Agile, beginning with user stories, the details are arrived at collaboratively between the Product Owner and the team, building something and putting it in front of the Product Owner for a test drive, and iterating and incorporating his/her feedback until the feature reflects what the Product Owner wants.
Not All Truths are Self-Evident
To some (both business and development), moving from generating and following detailed, prescriptive requirements to using user stories and face-to-face collaboration will be liberating… "Finally!...free from all the overhead!" But for others, it will like being made to walk that tightrope without the net, and their reaction can be visceral. Some Product Owners will feel that if they don't put all the detail in the requirements, they won't get what they want, or something will be missed. Some developers actually prefer the prescriptive development model of "just tell me what you want me to build and I'll build it." If you've embraced user stories and the benefits they and collaboration offer, that way of thinking will likely make little sense to you. You may even have a deep desire to stand up in a team meeting and proclaim "We hold these truths to be self-evident, that ALL Agile tenets are created good!" But you have to understand that some people are just not wired that way. Agile is a culture and a mindset, based on the Principles and Values of the Agile Manifesto. If your Product Owner or team members don't share those principles and values, you'll have a difficult time debating the merits. Remember, all the logical arguments in the world about how user stories are better won't matter to them. We're talking about perception of security here, and possibly even emotion, so it becomes subjective rather than objective.
So how do I make the move?
It's far more difficult to get people to remove detail from requirements than to add it. When faced with stiff opposition on this front, try putting the requirements through the same processes and rigor you would use to declare a user story to be "sprint ready":
- Engage the team in backlog grooming on those requirements. This will get the conversation between the team and business started sooner, and can open their eyes to the magic of collaboration in discovering that they need less detail spelled out in advance than they previously thought.
- Ensure that the 5 W's are present and clear in every requirement, and that the "How to" is not.
- Require every requirement to pass the INVEST acronym test: Independent, Negotiable, Valuable, Estimable, Sized appropriately, and Testable.
- Make sure also that each requirement has well formed "acceptance criteria" – just a few (maybe 2-5) clearly stated criteria, expressed again in language any user can understand – that tell us when the requirement is met. It gives you a clear script to demo against in the demo at the end of the iteration.
- The other extensive details can be covered in test cases, and their pass/fail can be reported succinctly in the final demo rather than walking through each flow in an all-day meeting.
