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

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:

  • The three “C’s of a user story
  • How user stories can  increase outcomes while reducing output
  • Common pitfalls when using user stories (and how to avoid them)
  • How to know when a story is ready

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 <role>, I want <what they want to do> so that <goal>”. 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.

  • Independent implies that each story is an independent piece of functionality that could work on its own.
  • Negotiable means that stories are a projection of what we think we’re going to do and they’re open to negotiation about what is included in each story.
  • Valuable means that each story has a value to the user based on the “why” portion of the story. We also make sure they’re valuable by writing them in plain English so that anyone can understand them.
  • Stories are estimable, meaning that we understand enough about the story to be able to estimate its size.
  • Small (or sized appropriately) refers to the idea that near term stories need to be small enough to start and finish in a single iteration; ideally fit in half or less of the sprint duration.
  • Stories must also be testable and the criteria must be clear and measurable.

 

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.

  • Can you describe our technical approach for how we’re going to build the solution?
  • Can you describe how we’re going to prove we haven’t broken something else by building this?
  • How are we going to demonstrate the result of this story when it’s complete to show that it meets the acceptance criteria?

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.