What users want
I just read Joel Semeniuk’s blog about personas. If you don’t feel like jumping over to Joel’s blog and would rather get the executive summary, he’s saying that personas are really useful for understanding the value and direction of a user story. I’m with Joel on the value of personas. There is something else, however, related to users that I felt moved to write about – user stories and what users “want”.
Regardless of whether a team has devised personas or not, I tend to see user stories written too much from a what-the-software-does perspective. I’ll just use Joel’s off-the-cuff example for a user story, reproduced below, as an example to highlight this failure mode that so many teams suffer from:
Feature: Shovel Snow
As a Home Owner
I want to Shovel Snow
So that I can get out of my driveway to get to work
Fairly simple and universally understandable user story, right? (Assuming you know what snow is. Not all people do. Although even Floridans seem to get blizzards these days.)
So what’s the failure mode here? Home owners don’t want to shovel snow. They want snow to be removed from their driveway. Shoveling snow is something they accept as a solution because they don’t have an alternative in mind. What we should aim to do with user stories is to provide the connection between a user’s goals – what they need – and a placeholder for how we might give them just that.
Who knows, maybe the home owner would rather pay for a heated driveway than pick up a snow shovel. If we write down stuff about shovels, it’s that much less likely that anyone will think of offering such a drastically different alternative such as laying pipes under the driveway. Or replacing the Cooper Mini with a 4×4 SUV.
To illustrate what we’re talking about here, let’s see how we might rephrase Joel’s example:
Feature: Accessible DrivewayAs a Home OwnerI want my driveway to be cleared of snow
So that I can drive in and out of my driveway to get to work
7 Comments
Trackbacks and Pingbacks
Comments are closed.
This provides a good case for using the Magic Wand technique. When the user claims they want a shovel, wave an invisible magic wand over them and say, “You have a shovel. What will you do with it?” Keep asking that question until you get to the problem they’re trying to solve, then start there looking for alternative (either cheaper or more valuable) solution.
We teach this technique and several others as part of http://www.productsashimi.com
Completely agree. Part of a story writing is establishing personas for the features and the product. This helps manage the personas needs per feature. Good reminders here.
Great post, Lasse. User stories like this are just the first step to the dreaded engineering story, “As a application, I want a web service to retrieve the data from the database.”
(First, I apologize in advance for writing something of a mini-rant.)
I like the revised story. Not because it refrains from describing a solution, but because it draws a better boundary around the solution space.
Like the original statement, revised story also posits a solution: Access the driveway by car. Describing it as a condition disguises its solution-ness slightly. Still, it’s a solution.
I don’t think that’s a flaw. I think it’s a necessary element of any well-written story. That point of automating a system is to make it carry out responsibilities on our behalf. The system’s role is to solve a problem for us (the “I want” part), as a component of our solving some more important problem (the “so that” part).
J.B.’s Magic Wand is a terrific tool–indeed, I consider it the most powerful tool in my consulting toolkit. The challenge is that magic wands are infinitely waveable. There is no place where we reach “the real problem.” You can always wave the wand again. “*Wave* You can get to work quickly, safely, and inexpensively. What will that do for you?” Well, I can do my work and make money. “*Wave* Your work is done, your customers are satisfied, and you have have piles of money. What will you do with that?” Every answer to the Magic Wand question is itself a step along the way to serving a yet deeper need.
The tricky thing with magic wands is to know when to stop waving. For me, the stopping point has entirely to do with where I draw the boundary of the system. My stopping rule is something like: Keep asking until the answer falls clearly outside the system’s responsibilities. Then back up one step, and assign that responsibility to the system.
Magician: *Wave* You have a shovel. What will you do with that?
Me: I’ll remove snow from my driveway.
Magician: Is that something you want the system to do?
Me: Yeah, sure, I guess.
Magician: *Wave* The snow is gone. What will you do with that?
Me: I’ll drive to work.
Magician: Going to work. Is that something you want the system to do, take you to work?
Me: No, I’ll drive. I like driving. I just want the snow gone so I can do that.
Now we’ve crossed the boundary. So we stop waving the wand (for now), and back up one step to find the “outermost” thing we wanted the system to do: Make the snow gone. That’s the responsibility we give to the system.
I think this “boundary test” is often the missing element in conversations about system responsibilities. Individually we’re always applying boundary tests, our personal idea of what’s inside the system and what’s outside. But we may not make them explicit. By leaving our boundary tests tacit, we open the conversation to debates about whether something is a solution or a goal, a what or a how, a requirement or a design choice. The distinctions between each of these dichotomies lies entirely in where we draw the boundary of the system. I think we would do well to make our boundary choices explicit.
I like the ideas behind re-writing this story to keep the solution separate from the story. However, as a one of the home owners in Joel’s story (we both live in Winnipeg, Canada), I think we need to add ‘snow’ back into the story. The snow is part of my problem (the ‘why’), and therefore would affect the scope of the story and its solution. Example:
As a Home Owner
I want my driveway to be cleared of snow
So that I can drive in and out of my driveway to get to work
If we leave the story without the snow, the scope of this story is too variable. For example, if my driveway is blocked because a tree fell, or because I’ve emptied the contents of my basement onto the driveway after a basement flood (due to all the melting snow), then the solutions to those 3 problems would be much different and our scope is too uncertain. The solution shouldn’t be part of the story, but the scope needs to be understood.
P.S. While having a heated driveway sounds like a nice idea, it probably would work better in a climate where the temperature goes above freezing once in a while during the winter. If I installed a heated driveway, the top of my driveway would be nice and clear, but I would have a permanent and rather large ice rink at the end of my driveway and onto the road from November until April. Great for skating, but not for walking or driving.
Even with the magic wand technique, the conversation is still bound to the mechanism of value creation. Much more powerful is to ask the question “how will you know (you got the value)?”
Which leads much more quickly to: “I can get in and out of my driveway when it snows” and encourages additional value clarity, like “I don’t have to spend more than 10 minutes a day”.