In this episode, we discuss the different types of items that may make up a product backlog.  Hint: It’s more than just User Stories.

After listening to this episode, you'll understand:

  • The difference between a Product Backlog and a Sprint Backlog
  • How to differentiate between Epics, Features, and Stories
  • The components of a good User Story
  • What the other types of backlog items are

Show Notes

I often see teams struggle with backlogs and managing the items within their Product Backlogs.  There’s more than just User Stories in backlogs too.  There could be Epics, Features, Technical Stories, Spikes, and Job Stories to name a few.

What’s the difference between Epics, Features, and Stories?  Size.  Epics and Features are really just really big User Stories.

Features are User Stories that are too big to fit into a Sprint.  They should provide value from the customer perspective and describe the problem or need instead of the solution.  Ideally, features should include acceptance criteria formed through a conversation.

User Stories are thin slices of value described from the customer’s perspective.  Stories should include acceptance criteria developed by the team through a conversation.

 

The Three Cs of a User Story

Card – Stories should be brief and should not contain all of the detail.  Stories are a reminder of a conversation that will include discussion of the details.

Conversation – More important than the template of a story is the conversation.  Every team member should understand the story through a dialogue and be able to discuss details that may change the original story or acceptance criteria (if any is written prior to the conversation).  Keeping stories small and without a lot of detail will lead to a richer, more meaningful conversation.  Larger, more detailed artifacts lead to assumptions and a lack of a conversation.

Confirmation – The story should include conditions of satisfaction to know the scope of the story and understand when the story is done.  The acceptance criteria for a story could be refined into Gherkin format.

 

Beyond User Stories

System User Story: A strong preference should be placed on creating user-centric stories.  However, some teams may work on development that does not interact with end users.  In these cases, the role of the user can be a system or device.

Technical Stories: If a team needs to develop functionality needed to implement a number of other user stories or otherwise support the system, their story might not directly impact the end user.  Examples include stories focused on non-functional support of the system, stories that address technical debt, or stores focusing on performing architectural work.

These stories may use technical rather than user-centric language.  The story should still express the ‘why’ (so that . . .) to ensure the motivation of the story is understood.  Technical stories can be used when the scope of the work is contained within a single component/platform and there is no obvious external user or system consuming/benefiting from the result of the story.

The format may be something similar to “Implement ____________ so that __________.”

 

Other Types of Stories

Spikes: A quick and dirty implementation designed to be thrown away and used to gain knowledge.  A common indicator that a spike should be used is when the team is unable to estimate a user story effectively.  An effective approach is to word spikes as a question to be answered or an assumption to be validated so that you know whether or not you accomplished the goal of the spike.  A spike can be written as “In order to <achieve some goal> <a system or persona> needs to <some action>” or other formats.  Spikes should be timeboxed and include acceptance criteria where possible.

Research: Broad, foundational knowledge-gaining to decide what to spike or give the ability to estimate.  This is often used when teams don’t know a potential solution.  An effective approach is to word research as a question to be answered or an assumption to be validated. Research stories should be timeboxed and/or include conditions to be satisfied (when are you done?).

Tracer Bullets: A very narrow implementation in production quality of an epic or large user story.  Tracer bullets are often used when the user story is too large in estimation.

 

Listen to the full episode to understand the different types of backlog items and how to use them.

 

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 and other podcatchers.

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.

.Subscribe on iTunes  Listen on Google Play Music  Available on Stitcher Radio  Subscribe on Android