Learn about The Product Backlog
According to the Scrum Guide, a product backlog is:
an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
A product backlog is a place where a product manager keeps a list of all desired future improvements and suggestions for improvements.
When a product manager receives requests for product improvements from sales, marketing, legal, and other departments in the organization, it is important to store these requests somewhere - and the product road map is the place. Whether the product manager uses a spreadsheet, a text document, a wiki, or road map management software, the important thing is that the backlog should be where these requests are added.
Dive into User Story Mapping
Agile evangelist and author Jeff Patton wrote a book called User Story Mapping that introduced the concept of a backlog that linked together various elements including:
Desired activities that a user wishes to do.
Sub-tasks that comprise these activities.
User stories from our product backlog.
A visual map of how these user stories relate to these activities and tasks.
How those user stories can fit into sprints and releases.
This process of creating this visual map of the user stories in a product backlog and the related release plan is called user story mapping!
User Activities and Tasks
User story mapping arranges user stories to how every day people do things they care about. Start by mapping out how users would do things in the real world - in chronological order.
For example, you need to change apartments in a week's time. You might have a set of activities like this:
Order moving boxes.
Pack belongings.
Move belongings into the new apartment.
Unpack everything and find a place for it in the new apartment.
Each of the activities breaks down into a set of tasks. For example, packing your belongings could consist of the following tasks:
Throw out stuff you don't need.
Pack all of your stuff into boxes.
And similarly, the moving your belongings could involve:
Put stuff into the moving van.
Drive to new apartment.
Unpack the boxes from the van.
Pay the driver.
Define Activities
The first step is to form the backbone of the user story map. that is the core flow of user activities and tasks that you want to help your users to achieve.
Do this by creating the core set of activities and order them chronologically.
Add Tasks
Once you have created a set of chronological activities, the next step is to break them down even further into a set of tasks.
For an activity like ordering moving boxes, there might be a set of tasks like this:
Search online for moving boxes.
Make a list of prices.
Book with credit card.
You should then make a list of tasks for each activity!
Add User Stories
The next thing is to map the user stories that are in your backlog to their corresponding task. Your user stories are written in the following format:
As a < type of user >, I want < some goal > so that < some reason >
Properly-written user stories mention the user and the goal they want to achieve so it should be possible to map each to a task without too much trouble.
Understand Features, Epics, and User Stories
In Scrum, you store requirements as user stories.
Remember that epics are big requirements that are typically broken down into several user stories. Features are even bigger requirements that can break down into epics.
In the example below, the feature is "create a list of favorite hotels." This breaks down into several epics including:
Create new list of hotels
Add hotels to list
Share list with friends
Delete a list
Make the list public
The reason these are epics is that they are still too big to estimate. Each needs to be broken down into user stories before estimating!
If you take the first of these epics, "create a new list of hotels," then this could break down further:
Create "My LIsts" section in the website.
Put the new "add to list" button on each hotel page.
Allow naming of the list.
View the list and the hotels in it.
Remove a hotel from the list.
These are closer to being estimable.
Note that the user stories in the yellow column above are not in story format due to space restrictions.
If these were to be used by a Scrum team as requirements, they would need to be in user story format.
Map Activities and Tasks to Features and Epics
With user story maps, activities map well to features you may have in your product backlog and tasks map well to epics.
Knowing this helps when you want to add user stories to your activities and tasks.
This means you can take any existing epics or features and try to add them to your story map.
The following chart helps to explain this equivalence.
Let's Recap!
A product backlog is a list of future changes in the product.
By thinking in terms of user activities and tasks, you can build the product in a sequence that delivers value to your users.
Do this by creating a backbone of activities and tasks ordered chronologically.
Add user stories underneath the backbone which effectively map the existing user stories in your product backlog into a far more visual form - the user story map!
Additional Resources
A nice slideshare on identifying the mental models of customers.
A great podcast with Jeff Patton.
When you have added user stories to your user story map, they becomes an excellent tool for planning releases and applying Agile estimation. You will see how that can be done in the next chapter!
