Helping teams to shift from a task-focus to writing user stories requires a different approach than simply introducing user stories as a new tool. You have to adapt the existing practices, by changing how teams think about and discuss the work they do. “Change from…” is different for people than “Start with…”
Here’s how I help them shift.
Work Breakdown Structure
In the late 1990s, before we had user stories (Kent Beck introduced them in the 1990s, but we did not have them yet), we used work breakdown structures in our project estimation and planning activities. Yes, the world of Gantt charts and functional decomposition.
A work breakdown structure (WBS) as a functional decomposition makes sense when you know (a) exactly what you want to build, (b) exactly how it needs to work, and (c) generally how you want to build it. The large work item – the output you intend to create – is conceptually split into multiple smaller work items which can be independently tracked, managed, and delivered.
This process is called decomposition. The whole equals the sum of the parts.
The work of delivering an updated shopping cart (perhaps collecting an alternate shipping address) would be broken down into the work to update the UI to collect the additional information, and an update to the database to record the information, as well as an update in the fulfillment system to honor the alternate shipping address.
When you are outcome-oriented or otherwise customer-centric, you cannot know exactly what needs to be built, much less how it needs to work, so this approach is – to put it kindly – “not positioned for success.”
The trick, however, is that the WBS, while useful for a developer in estimating the effort to build a “known thing,” is not useful as a planning artifact for outside the team. The certainty about what to build prevents the team from learning a better way – there’s no room to ask the question. So we change the conversation.
Asking a Different Question
There are explicit causal relationships between the work the team is thinking about, and the outcomes they need to be thinking about. All of the development tasks are a decomposition of the work needed to build whatever thing the team was planning to build. I start here, with questions to uncover the hidden rationale.
What thing is this task a part of? The team always has a good answer immediately – they are already thinking about the structural context of what they are building. “This API is part of the new Ability to choose a different item feature.”
The task is adding an API. The thing is the feature – the ability to choose a different item.
What need is that thing addressing? Why does the user need the ability to choose a different item? Sometimes this information is already in the background, it came up in discussion – the product person expressing the request to add the feature provided this causal-context in conversation. “The default choice is only good for 75% of people, the other 25% need to be able to choose a different feature. We need to build that into the UI.”
Sometimes, no one has talked to the developers about why they want something to be built, the requestor just adds it to a list of items to be built, like placing an order in the fast food line. “Build the ability for users to choose a different item” with no context, rationale, or clarification.
What I’m doing is bringing that need from the background to the foreground. When it isn’t present, I ask the team to take a pause and find the rationale. This is how we shift from tasks to user stories.
Half of a User Story
This allows the team to change their orientation from a focus on the thing to be built to a focus on the need to be addressed (usually a problem to be solved).
With this shift in focus, I introduce the syntax of the first half of the user story.
As a {type of people}, I need to {exhibit a behavior}.
As a {visually impaired person}, I need to {select high-contrast colors for my report}.
The first half of the story identifies the user for whom we are trying to make something better, or make something possible. The teams pretty consistently have a behavior already pre-conceived (selecting high-contrast colors) so this step is easy.
What we’ve done now is start to articulate the problem to be solved by describing the situation (visually impaired people cannot select high contrast colors with the current product). We haven’t addressed why this is a problem, but we’ve started the ball rolling down the hill.
Suddenly the team has an opportunity to build momentum.
The Other Half of the User Story
Just knowing the situation exists is not enough, the team needs to share an understanding about why this is a problem and what the users consider to be acceptable. How do the users define if the problem has been solved? The team could implement the ability for a user to specify the hex codes for the desired colors (#660000 is the hex code for Tyner Blain maroon, for example) and consider it done. By allowing users to specify any color, they have made it technically possible to select high-contrast colors. They’ve also made it unlikely that they will have solved the underlying problem. I help the team move past the observable behavior to center instead on the underlying purpose – what problem is the user solving when they exhibit the behavior?
The user story helps the team to align on a “so that.”
As a {type of people}, I need to {exhibit a behavior} so that {I can meet my goal}.
As a {visually impaired person}, I need to {select high-contrast colors for my report} so that {I can avoid visual fatigue}.
This is the second step of the shift for the team – to see the difference between a situation (cannot select high contrast colors) and a problem (user experiences visual fatigue).
Reorienting the Team From Outputs (What) to Reasons (Why)
The team first moves from what they plan to build to how someone would use it (easy), then moves from how someone would use it to why someone would use it (harder).
Approaching the shift in two steps makes it easier because each step is smaller, and also easier because the team starts to build energy. A task (add an API, for example) is neutral – just something to do, it doesn’t prompt any questions. An identified behavior is also neutral-ish, but it does at least prompt the question of why someone would do it. And then you have a goal.
Once you have a goal, you can ask other questions.
- Will this approach work?
- Would the users find this approach empowering?
- Would people prefer this approach or that approach?
None of those questions has a way to attach to a task. They all stick to a user story
