Giving up control over outcomes
Does the common user story format describe a design outcome for a customer? I suspect that product leaders are leaving team creativity and value on the table when writing user stories this way. They are controlling possible outcomes rather than describing the problems to solve.
Consider this user story example from Mike Cohn and see what picture forms in your mind:
“As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.”
The format used is: “As a <type of user>, I want <some goal> so that <some reason>.”
The “user” benefit (or reason) is “so that my backup drive isn’t filled up with things I don’t need saved”. Cohn describes the goal as “I can indicate folders not to backup”.
“Indicating folders not to backup” is one possible design choice/outcome from the product leader to solve a problem that is implied in the benefit. The problem seems to be no control over what is being backed up or, digging deeper, the backup solution doesn’t know what is important to keep. Will the team creatively solve this problem or just create a way to indicate folders to exclude from a backup?
If a product leader can accept that the development team is actually a team of bright problem solvers then the creativity of an entire team (instead of just one product leader) can be unleashed to create efficient, simple to maintain solutions to problems!
“It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.” — Steve Jobs
Stories are experiments
So how do product leaders give up control over outcomes in user stories and focus on describing problems? The agile manifesto encourages us to value “customer collaboration over contract negotiation” and of “responding to change over following a plan”. Joshua Kerievsky’s modern agile guides us to “experiment & learn rapidly”. Eric Ries’ The Lean Startup calls for “validated learning” that can be “validated scientifically, by running experiments that allow entrepreneurs to test each element of our vision”.
User stories are opportunities for real world feedback and “validated learning” that help us to change course, or “pivot” as Ries puts it, toward the best solution to a customer’s problem. These are experiments and we should treat them accordingly!
Testable statements
Experiments have a hypothesis and “a useful hypothesis is a testable statement, which may include a prediction” . While scientifically formalized hypotheses call for a testable proposed relationship (if) and an expected result (then), a user story should describe the relationship of an expected benefit for a customer if a specific problem is solved:
If a <specific problem> is solved Then a <customer> will get an<incremental benefit>.
Applying this format to Cohn’s example user story we could rewrite it:
If a backup solution knows what’s important to keep Then a user’s backup drive won’t be filled up with things they don’t need saved.
Writing a user story this way gives control of the design outcome to the team and opens up a larger pool of possible solutions. The value of working with a team of engineers and empowering them to do what they do best will decentralize the risk of “getting it wrong” AND will spread ownership of the solution to the whole team. When the team solves the problem they build greater empathy for the needs of their customer and that value grows over time.
Testing your stories
As an experiment, the team can test the user story/hypothesis to determine if they solved the problem for their customer (Does the backup solution know what’s important or not?). The team should also test if, by solving the problem, they’ve created the benefit for the customer they expected to (Is the user’s backup drive free of things they don’t need saved? Does it fill up anyway and we missed the real problem? Why do we need a backup drive at all?).
This is a crucial conversation to have with a customer, during a demo, as the team conducts a real world experiment to prove or disprove the relationship of solving a problem to generating a customer benefit.
A subtle change in user stories can yield significant benefits with a team’s happiness & sense of ownership and open more options for solutions. When a user story describes a design outcome, a product leader should dig deeper with the customer until they find a testable problem to solve!
Special shout out to Rob Gordick for his support while thinking through and writing this article and to Mike Cohn, the authors of the agile manifesto, Joshua Kerievsky, and Eric Ries for influencing my viewpoints in agile and entrepreneurship!
Further reading
- Wondering how to maximize the creativity of your team? Learn more about Building trust to learn as a team in the follow-up to this article
- If you’re working on new products check out how to Prioritize a backlog like an entrepreneur
- Want to keep the conversation going? Reach out on LinkedIn
