The product backlog

Overview

From Wikipedia:

The product backlog is a high-level document for the entire project. It contains backlog items: broad descriptions of all required features, wish-list items, etc. prioritized by business value. It is the “What” that will be built. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the timeline and, to a limited extent, priority. For example, if the “add spellcheck” and “add table support” features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI is higher.

Three types of user stories can be defined in theSCRUM:

• Epic - when a user (read “That’s not a user story, that’s an epic” to know more)
• Story - (read this article if you are not familar to user stories)
• Spike - to manage experiments or research (know more about spikes)

Here are the management rules regarding user stories:

• A story or a spike can be standalone or can belong to an epic.
• A standalone story or spike can be changed into an epic.
• An epic cannot be changed into a standalone story or spike.
• An epic can contain one to many stories or spikes.

Managing stories

To create a new standalone story or spike or epic in the product backlog, use the “Add a new story” available above the product backlog.

To add a new story or spike to an existing epic, use the “Add” icon available on each epic.

To edit a story, click on any field you want to update… That is the magic of inline editing

Editing stories

Property	Description
#	The internal ID of the story; displayed as it can be used as reference
Prio	Priority of the story in the product backlog. The higher the priority is, the more important the story is. The main benefit of this choice is to allow adding a new item at the very top of the backlog without changing the priorities of the other stories. It is recommended to use steps when setting up priorities, in order to ease the insertion of new stories (i.e: 250, 220, 200… so that it is easy to insert a new story with priority 230). If a story belonging to an epic has a priority higher than the current priority of the epic, then the priority of the epic is updated to this new priority. When changing a priority, the story is automatically moved to its new position in the product backlog; no need to refresh the page.
Estim	Estimation of the story, expressed in hours or story points (set for the whole project). There is no rule to automatically set the estimation of an epic based on the sizing of its sub-stories.
%	Percentage of completion of a story. There is no rule to automatically set the percentage of a story based on its belonging tasks, or to set the percentage of an epic based on the percentage of its sub-stories.
User story	The user story itself. When creating a new story, theSCRUM suggests the following template to fill the story: “As a [role], I can [feature] so that [reason]“.
	A click on this icon triggers a pop-up to edit notes on the story. Can be useful to put some documentation, links, images… to better explain the story.
Acceptance criteria	The acceptance criteria for the user story. When creating a new story, theSCRUM suggests the following template to fill the acceptance criteria: “Given [context] and [some more context]… When [event] then [outcome] and [another outcome]“.
	A click on this icon triggers a pop-up to edit the details of the story: change the type of the user story, adds some tags, assign the story to a release.
	Delete the story. For an epic, all sub-stories are deleted. All tasks in the sprint backlogs belonging to this story or its sub-stories are also deleted. You should not delete a story when it is done, but rather mark it as 100% completed.
	Only available on epics. Allows to add a sub-story to the epic.

Editing the details of a story:

Deleting a story:

Editing story notes:

Viewing the product backlog as story map

Story map is a different way of representing a product backlog; it’s indeed more than that, and you would want to read this very inspirational article “The new user story backlog is a map” that describes the benefits of story map over the classic product backlog view.

Story maps in theSCRUM are a read-only view of your product backlog; the view is interesting to exchange and discuss with the team, but the main view to create and update the backlog remains the classic product backlog view.