The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.
(source: The Scrum Guide ™ 2017 https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog)
The Scrum Guide only recognizes Product Backlog Items (PBIs). How these items actually look like is left open by the Scrum Guide. What follows are some common practices to communicate these PBIs.
User Stories are a common convention for writing PBIs. Instead of describing the work to be done, they capture the need or wish of the user that the work will fulfill, leaving the implementation details open to discussion.
A common format for User Stories is:
As a …. <role/persona>
I want …. <behavior>
So that … <value>
(source: Mike Cohn, User Stories Applied (Boston: Addison-Wesley, 2004), 135.)
As a Line Manager
I want to see an overview of my subordinates’ contract expiry dates
So that I can renew contracts on time
The benefit of the User Story over the more straightforward “to do” task is that it encourages conversation by providing context. Imagine we had the following task instead of the above User Story:
Create a table showing the name of the subordinate and their contract expiry dates
It could very well be that when the team implements the User Story they will end up with this exact screen. But it could also be that upon reading the User Story the discussion on how the Story’s intent could be achieved would bring up new suggestions that weren’t thought of when the ticket was created. Maybe instead of creating a whole new screen, the same value could be delivered with less work simply by sending a reminder email before a contract is about to expire?
By providing the context as to WHY we’re building this feature and omitting the HOW, the User Story encourages conversations, unlike the to-do task which simply dictates what is to be done.
Common User Story pitfalls
Technical Persona: You want to avoid choosing a persona that represents a technical role. Examples to avoid: “As a Product Owner I want feature X So that we could later implement feature Y”, or “as a developer, I want unit tests so that the code will be easy to refactor”. These kinds of non-user stories discourage the capturing of intent and return us to thinking in terms of solution. User Stories should only be used to capture the needs of your users or stakeholders. A stakeholder example would be your legal department requesting that the system would be GDPR compliant so that the company would not be sued. That’s a valid User Story.
Too broad of a persona: If all your User Stories start with “As a user I want..”, you’re omitting vital context. Your users are not all the same and their wishes are not uniform. Try to capture the user’s subgroup, state of mind, or intent when they have the need you’re addressing. “As an angry reader I want…” is immediately more evocative than “As a user I want…”.
Epics are items that are too big to fit into a Sprint (Epic = Long story). In Scrum the team is expected to choose PBIs it can complete within a Sprint when planning. However, not all PBIs are small enough to be completed within a Sprint. Before pulling them into a sprint they need to be broken down further until they can fit, which is often done as part of a Backlog Refinement. Refining PBIs is time-consuming and therefore you typically only want the highest priority PBIs in your backlog refined, those that are likely to be pulled into the upcoming Sprint.
Epics allow you to keep items in your backlog without investing time in refining them. They represent work to be done that only needs actual refinement when their time to be implemented is approaching. At that point, they could be broken down into multiple User Stories so that the work can fit in a Sprint.
Typically the highest priority items in the backlog are User Stories, and as you go down the Backlog you see more Epics.
Common Epic pitfalls
Open-ended Epics: Some management systems (e.g. Jira) encourage the use of Epics as containers for certain types of activities. There could be a “Technical debt” Epic to contain all technical debt stories or “Checkout Page” Epic to contain any work related to that page. Of course, Technical Debt is never fully paid off and the Checkout Page could always use more work, and therefore these container Epic tend to never be removed either, leading to an ever-growing list of immortal Epics that is tough to manage. Create Epics with specific intent and once that intent is captured by Sprint sized stories, remove the Epics.
Highly detailed Epics: The intent of Scrum is to complete work and release working software on a regular basis in order to facilitate learning over your product and your market. Learning is then captured in the backlog by adding, removing, or modifying PBIs. Therefore the content of your lower priority items on your backlog tends to be volatile. You don’t want to spend a lot of time defining these items as their content can and should change as your product evolves. The time you spend defining these items in detail will be wasted once they need to be modified due to changes in the system or the system’s context. The detailing work should come when the Epics are broken down to Sprint sized User Stories.