Sign up to save your podcasts
Or
Share MBA042: Stop Using User Stories – Interview with Jim Benson
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
MBA042: Stop Using User Stories – Interview with Jim Benson
In this episode, author, speaker, and Kanban pioneer Jim Benson advises us to ditch User Stories and shows us what to do instead. Jim’s recommendation: use the scientific method.
Jim Benson
CEO of Modus Cooperandi
Jim Benson is an internationally recognized speaker and author. He is a pioneer in applying Lean and Kanban to knowledge work, and his books include Personal Kanban and Beyond Agile.
Jim is CEO of the collaborative management consultancy Modus Cooperandi and founding partner of Modus Institute.
http://traffic.libsyn.com/masteringbusinessanalysis/MBA_042__Stop_Using_User_Stories_-_I.mp3
After listening to this episode, you'll understand:
Show Notes
In the last few episodes, we’ve discussed how you can be effective using User Stories. Now, thought leader Jim Benson suggests that we should stop using User Stories in favor of an approach better aligned to the scientific method.
The Problem with User Stories
Jim’s main issue with User Stories is that they’ve moved away from their original intention and become functional requirements in a pretty wrapper. Developers read the User Story (functional requirement) and build it. This assumes that the who, what, and why of the User Story is correct and it will properly address the business goal.
We started using User Stories because we lacked empathy towards our customers. However, we still took our own assumptions that we used to put in the detailed design document and put it in the wrapper of a User Story.
Use a Hypothesis
In reality, everything we’re doing is an assumption or a hypothesis. When we present ideas as a hypothesis, we’re saying three things:
A well-crafted hypothesis will encapsulate everything that agile is supposed to do in a more honest way.
The original thought behind User Stories is that the team could write them. As we’ve moved away from that original intent, the Product Owner often writes the story with their assumptions, pushing them on to the team. Using a hypothesis allows us to have better conversations about our assumptions and goals.
Getting Started
To get started using a hypothesis instead of a User Story, we must first understand the organization’s goals for the next three months. This is what the organization wants to accomplish in the next three months, which Jim calls “strategic intents”. Get everyone in the organization together to discuss the strategic intents so that everyone is aware of the goals. Everyone can then share their ideas as to how to support those strategic intents.
Ideas are then gathered into big bets and small bets. Big bets are similar to projects, but Jim finds that if you call them bets, people make them smaller (up to one month). All of the ideas and strategic intents are based on hypotheses.
Because most organizations don’t do this, you can start by decomposing your User Stories by challenging your assumptions about who the customer really is, what you’re trying to achieve, and how you would test that. Then take that information and create a hypothesis.
Hypothesis Design
A hypothesis might be stated as: We believe that if we do , we will get , and we will test it by . You should also think about and articulate who your customer is.
The hypothesis has initial acceptance criteria and tests to understand when the code is complete and working properly. It also has acceptance criteria and metrics based on after the solution is implemented and people interact with it to understand how (if at all) the solution impacts the strategic intents. This allows organizations to rapidly learn and adapt.
A hypothesis still follows the three “Cs” of a User Story; Card, Conversation, and Confirmation. The hypothesis should be short (fits on a card), it needs to be discussed to understand and challenge assumptions (conversation), and it has acceptance criteria (confirmation). A team can use spikes to experiment and learn what will work.
Jim’s approach to using a hypothesis drives collaboration, adaptability, and creates a learning organization.
Z
Your Homework
Take a few User Stories (especially those that the team is doubtful about) and rewrite them as hypotheses. Treat it like a guess that you can prove or disprove and learn something.
What are your thoughts?
Have you used any variations on User Stories? Please share your experience and comments in the section below.
Links mentioned in this episode:
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
The post MBA042: Stop Using User Stories – Interview with Jim Benson appeared first on Mastering Business Analysis.
View all episodes
By Dave Saboe, CBAP, PMP, CSM | Certified Business Analysis Professional | Agile Coach
4.7
8282 ratings
In this episode, author, speaker, and Kanban pioneer Jim Benson advises us to ditch User Stories and shows us what to do instead. Jim’s recommendation: use the scientific method.
Jim Benson
CEO of Modus Cooperandi
Jim Benson is an internationally recognized speaker and author. He is a pioneer in applying Lean and Kanban to knowledge work, and his books include Personal Kanban and Beyond Agile.
Jim is CEO of the collaborative management consultancy Modus Cooperandi and founding partner of Modus Institute.
http://traffic.libsyn.com/masteringbusinessanalysis/MBA_042__Stop_Using_User_Stories_-_I.mp3
After listening to this episode, you'll understand:
Show Notes
In the last few episodes, we’ve discussed how you can be effective using User Stories. Now, thought leader Jim Benson suggests that we should stop using User Stories in favor of an approach better aligned to the scientific method.
The Problem with User Stories
Jim’s main issue with User Stories is that they’ve moved away from their original intention and become functional requirements in a pretty wrapper. Developers read the User Story (functional requirement) and build it. This assumes that the who, what, and why of the User Story is correct and it will properly address the business goal.
We started using User Stories because we lacked empathy towards our customers. However, we still took our own assumptions that we used to put in the detailed design document and put it in the wrapper of a User Story.
Use a Hypothesis
In reality, everything we’re doing is an assumption or a hypothesis. When we present ideas as a hypothesis, we’re saying three things:
A well-crafted hypothesis will encapsulate everything that agile is supposed to do in a more honest way.
The original thought behind User Stories is that the team could write them. As we’ve moved away from that original intent, the Product Owner often writes the story with their assumptions, pushing them on to the team. Using a hypothesis allows us to have better conversations about our assumptions and goals.
Getting Started
To get started using a hypothesis instead of a User Story, we must first understand the organization’s goals for the next three months. This is what the organization wants to accomplish in the next three months, which Jim calls “strategic intents”. Get everyone in the organization together to discuss the strategic intents so that everyone is aware of the goals. Everyone can then share their ideas as to how to support those strategic intents.
Ideas are then gathered into big bets and small bets. Big bets are similar to projects, but Jim finds that if you call them bets, people make them smaller (up to one month). All of the ideas and strategic intents are based on hypotheses.
Because most organizations don’t do this, you can start by decomposing your User Stories by challenging your assumptions about who the customer really is, what you’re trying to achieve, and how you would test that. Then take that information and create a hypothesis.
Hypothesis Design
A hypothesis might be stated as: We believe that if we do , we will get , and we will test it by . You should also think about and articulate who your customer is.
The hypothesis has initial acceptance criteria and tests to understand when the code is complete and working properly. It also has acceptance criteria and metrics based on after the solution is implemented and people interact with it to understand how (if at all) the solution impacts the strategic intents. This allows organizations to rapidly learn and adapt.
A hypothesis still follows the three “Cs” of a User Story; Card, Conversation, and Confirmation. The hypothesis should be short (fits on a card), it needs to be discussed to understand and challenge assumptions (conversation), and it has acceptance criteria (confirmation). A team can use spikes to experiment and learn what will work.
Jim’s approach to using a hypothesis drives collaboration, adaptability, and creates a learning organization.
Z
Your Homework
Take a few User Stories (especially those that the team is doubtful about) and rewrite them as hypotheses. Treat it like a guess that you can prove or disprove and learn something.
What are your thoughts?
Have you used any variations on User Stories? Please share your experience and comments in the section below.
Links mentioned in this episode:
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
The post MBA042: Stop Using User Stories – Interview with Jim Benson appeared first on Mastering Business Analysis.
More shows like Mastering Business Analysis
View all
Freakonomics Radio
32,246 Listeners
The Ben Shapiro Show
153,989 Listeners
The Economics of Everyday Things
1,643 Listeners
Business Analysis Simplified
0 Listeners