Sign up to save your podcasts
Or
Share MBA040: User Stories – Are You Ready?
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
MBA040: User Stories – Are You Ready?
In this episode, Leslie Morse helps you get started with User Stories – what they are, common pitfalls, and how to know when a story is ready.
Leslie Morse
Managing Director at Davisbase Consulting
Business Analyst by trade, collaborative entrepreneur at heart; Leslie has over 15 years of experience in information technology, digital business strategy and consulting services. Her diverse experience across business and IT roles in start-up, small business, and Fortune® 50 organizations allows her to quickly assimilate to new client situations and rapidly uncover ways to add value.
After listening to this episode, you'll understand:
Show Notes
User stories are pretty simple; they’re nothing more than a construct for phrasing on option for something we could deliver to satisfy a customer. This differs from what we would traditionally think of as a product or software requirement. The word “requirement” is not the most appropriate because of the negotiable and adaptable nature of stories.
The most commonly used format for user stories has three parts; a role, a function that the role is trying to accomplish, and why they are looking to accomplish that function. Teams often use the “As a , I want so that ”. User stories help us to understand the who, what, and why behind the solution.
Some teams prefer to put the “why” first because that is often the most important component of a user story.
A user story is still incomplete with those three parts. User stories need to have acceptance criteria or conditions of satisfaction so that we understand what kind of a solution will meet the customer’s needs.
Acceptance Criteria
The simplest way to start using acceptance criteria is with a bulleted list of what would need to be true for the solution to be acceptable.
Acceptance criteria gives us boundaries for what’s good enough, which helps us understand when to stop and avoid gold plating the solution. Acceptance criteria sets the parameters for what is “just enough”.
Think of acceptance criteria as a checklist of things you’re going to look for in order to make sure you have built the functionality to satisfy the user’s needs. It’s the first level of extra detail and clarity that gives us context for what it is we’re looking to build.
The story alone is not enough
Even with the acceptance criteria, a user story cannot convey all of the information needed to develop a solution. Some teams make the mistake of trying to imbed all of the details and specifications in the user story.
Agile thought leader Ron Jeffries talks about the three C’s of user stories. This approach helps us to better understand the intent of a user story. The three C’s are: Card, Conversation, and Confirmation.
We’re looking for user stories to fit on a small index card. While often the current practice is to enter the user stories into a software tool, keep the spirit of the physical card alive and keep your stories brief. A physical card that can be read from several feet away forces the user stories to be concise and exclude a lot of the detail.
If you can’t Tweet your user story, it’s probably too long.
Cards also serve as a physical placeholder for a conversation. The card is a single atomic product option about which we can have a conversation. In agile, documentation should be the result of a conversation and collaboration instead of a replacement for it. Cards don’t need to include a lot of the detail because the detail is provided through a conversation.
The confirmation is the acceptance criteria we mentioned earlier. It is used to confirm our understanding of the story and helps drive the conversation.
Why not create and refine all your stories upfront?
A large component of agile is about risk mitigation and cost of delay. Think of user stories as inventory. The more inventory you have in the warehouse, the more capital you have tied up in that inventory and if something changes, your inventory will go to waste.
The more we invent in this inventory of information, we’re increasing the risk that we’ve spent time building out details that we’ll never actually use. We need just clarity of user stories in the backlog for this release horizon.
INVEST in good user stories
Bill Wake created an approach for identifying the qualities of a good user story using the acronym INVEST. Invest stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Are we ready yet?
Teams should have a definition of done for their stories. The definition of done is the criteria that every story must meet to be considered complete.
Teams should have a definition of ready for their user stories. The definition of ready is the conditions that must be true for the team to pull a story into their sprint and begin working on it.
Leslie user four questions to help teams understand if a story is ready.
1. Do we have a shared understanding of the story? She uses three additional questions to qualify the shared understanding.
2. Given what we’ve learned based on our conversation about the story, do we feel that the story is sized appropriately?
3. Do we know enough about the story to plan our tasks?
4. Are any incoming dependencies fulfilled?
These four questions area good filter to understand that if the answer to all four are yes, we have a good understanding of the story and it is ready to start.
Z
Your Homework
1. If you’re never used user stories before, focus on quantity over quality. If you focus on perfection at the beginning, you’ll never get started.
2. Make time for cross functional collaboration. Remember that having good user stories and a well refined backlog takes time. You can’t put it all on the shoulders of the Product Owner. Each team member should make a little time to review the backlog and understand what’s coming up. They should also make time every sprint for backlog refinement to refine and get near term stories to a ready state.
What’s your take?
Do you use User Stories? Do you experience any challenges in using 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 MBA040: User Stories – Are You Ready? 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, Leslie Morse helps you get started with User Stories – what they are, common pitfalls, and how to know when a story is ready.
Leslie Morse
Managing Director at Davisbase Consulting
Business Analyst by trade, collaborative entrepreneur at heart; Leslie has over 15 years of experience in information technology, digital business strategy and consulting services. Her diverse experience across business and IT roles in start-up, small business, and Fortune® 50 organizations allows her to quickly assimilate to new client situations and rapidly uncover ways to add value.
After listening to this episode, you'll understand:
Show Notes
User stories are pretty simple; they’re nothing more than a construct for phrasing on option for something we could deliver to satisfy a customer. This differs from what we would traditionally think of as a product or software requirement. The word “requirement” is not the most appropriate because of the negotiable and adaptable nature of stories.
The most commonly used format for user stories has three parts; a role, a function that the role is trying to accomplish, and why they are looking to accomplish that function. Teams often use the “As a , I want so that ”. User stories help us to understand the who, what, and why behind the solution.
Some teams prefer to put the “why” first because that is often the most important component of a user story.
A user story is still incomplete with those three parts. User stories need to have acceptance criteria or conditions of satisfaction so that we understand what kind of a solution will meet the customer’s needs.
Acceptance Criteria
The simplest way to start using acceptance criteria is with a bulleted list of what would need to be true for the solution to be acceptable.
Acceptance criteria gives us boundaries for what’s good enough, which helps us understand when to stop and avoid gold plating the solution. Acceptance criteria sets the parameters for what is “just enough”.
Think of acceptance criteria as a checklist of things you’re going to look for in order to make sure you have built the functionality to satisfy the user’s needs. It’s the first level of extra detail and clarity that gives us context for what it is we’re looking to build.
The story alone is not enough
Even with the acceptance criteria, a user story cannot convey all of the information needed to develop a solution. Some teams make the mistake of trying to imbed all of the details and specifications in the user story.
Agile thought leader Ron Jeffries talks about the three C’s of user stories. This approach helps us to better understand the intent of a user story. The three C’s are: Card, Conversation, and Confirmation.
We’re looking for user stories to fit on a small index card. While often the current practice is to enter the user stories into a software tool, keep the spirit of the physical card alive and keep your stories brief. A physical card that can be read from several feet away forces the user stories to be concise and exclude a lot of the detail.
If you can’t Tweet your user story, it’s probably too long.
Cards also serve as a physical placeholder for a conversation. The card is a single atomic product option about which we can have a conversation. In agile, documentation should be the result of a conversation and collaboration instead of a replacement for it. Cards don’t need to include a lot of the detail because the detail is provided through a conversation.
The confirmation is the acceptance criteria we mentioned earlier. It is used to confirm our understanding of the story and helps drive the conversation.
Why not create and refine all your stories upfront?
A large component of agile is about risk mitigation and cost of delay. Think of user stories as inventory. The more inventory you have in the warehouse, the more capital you have tied up in that inventory and if something changes, your inventory will go to waste.
The more we invent in this inventory of information, we’re increasing the risk that we’ve spent time building out details that we’ll never actually use. We need just clarity of user stories in the backlog for this release horizon.
INVEST in good user stories
Bill Wake created an approach for identifying the qualities of a good user story using the acronym INVEST. Invest stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Are we ready yet?
Teams should have a definition of done for their stories. The definition of done is the criteria that every story must meet to be considered complete.
Teams should have a definition of ready for their user stories. The definition of ready is the conditions that must be true for the team to pull a story into their sprint and begin working on it.
Leslie user four questions to help teams understand if a story is ready.
1. Do we have a shared understanding of the story? She uses three additional questions to qualify the shared understanding.
2. Given what we’ve learned based on our conversation about the story, do we feel that the story is sized appropriately?
3. Do we know enough about the story to plan our tasks?
4. Are any incoming dependencies fulfilled?
These four questions area good filter to understand that if the answer to all four are yes, we have a good understanding of the story and it is ready to start.
Z
Your Homework
1. If you’re never used user stories before, focus on quantity over quality. If you focus on perfection at the beginning, you’ll never get started.
2. Make time for cross functional collaboration. Remember that having good user stories and a well refined backlog takes time. You can’t put it all on the shoulders of the Product Owner. Each team member should make a little time to review the backlog and understand what’s coming up. They should also make time every sprint for backlog refinement to refine and get near term stories to a ready state.
What’s your take?
Do you use User Stories? Do you experience any challenges in using 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 MBA040: User Stories – Are You Ready? 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