Scrum Term: (Product) Backlog
Within a scrum team you will find that the term “Product Backlog” or “Backlog” for short is used a lot. When we try now to explain this term in its simplest definition the Product Backlog is simply a list of all things that needs to be delivered as a result of the project. The backlog replaces the traditional requirements specification in the waterfall based methods, also known as artefacts.
These items have a very specific setup, can have a technical nature or can be usercentric and are always written in the form of user stories. The owner of the Product Backlog is the Product Owner. The Scrum Master, the Scrum Team and other Stakeholders only contribute it to make the product backlog a broad and complete To-Do list.
Having a Product Backlog, which is owned by the product owner, does not mean that the Scrum Team is not allowed to create and use other artefacts. Examples for additional artefacts could be a summary of the various user roles, workflow descriptions, user interface guidelines, storyboards, or user interface prototypes. However, these artefacts do not replace the Scrum Product Backlog but complement and detail its content. I have found in my projects the best way of capturing the teams input and breakdown related to the user stories is to create sub tasks, as a part of the original user story.
So summarising, a product backlog is a prioritised list of work for the development team that is derived from the road map and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first. The development team doesn't work through the backlog at the product owner’s pace and the product owner isn't pushing work to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it, either in a continuous way (KANBAN) or in an iteration after integration (Sprints) way (Scrum).
TIP:
Make sure all the user stories, discussion tasks and sub-tasks can be found in one issue tracker, like JIRA. Don’t use multiple systems to track bugs, requirements, and engineering work items. If it's work for the development team, keep it in a single backlog. This prevents thin from getting lost
A Product Backlog has certain properties that differentiate it from a simple to-do list:
an entry in the Scrum Product Backlog always add value for the customer
the entries in the Scrum Product Backlog are prioritised and ordered accordingly
the level of detail depends on the position of the entry within the Scrum Product Backlog
all entries are estimated
the Scrum Product Backlog is a living document
there are no action-items or low-level tasks in the Scrum Product Backlog (They are connected as sub-tasks to one of the backlog items)
In A typical Scrum backlog you will usually find the following different types of items (User stories:
Features
Bugs or issues
Technical work
Knowledge acquisition
Now we have established what a product backlog is and now you probably want to know how you can build a proper backlog?
It all starts with the road map and requirements. A customers or teams road map and requirements provide the foundation for the product backlog. Road map initiatives break down into several so called epics, and each epic will have several requirements and user stories. Let's take a look at the road map for an example of a product to book flight tickets ON LINE for the fictitious company Scrum Air
Since “Search & Book” is the first initiative in the road map, we'll want to break down that initiative into epics (shown here Yellow, Orange and Dark Orange) and user stories for each of those epics.
The product owner then organises each of the user stories into a single list for the development team (Proposed sprint backlog). The product owner may choose to deliver a complete epic first (Single Epic delivery). Or, it may be more important to the program to test show available flights which requires stories from several epics (Multi epic). See both examples below.
The Product Owner uses the Product Backlog during the Sprint Planning Meeting to describe the top entries to the team. The Scrum Team then determines which items they can complete during the coming sprint. So how is a product manager deciding what to do first? What may influence a product owner's prioritisation?
Customer priority
Urgency of getting feedback
Relative implementation difficulty
Symbiotic relationships between work items (e.g. B is easier if we do A first)
While the product owner has the duty prioritising the backlog, it's not done in a vacuum. Effective product owners seek input and feedback from customers, designers, and the development team to optimise everyone's workload and the product delivery.
A well-prioritised agile backlog not only makes release and iteration planning easier, it broadcasts all the things your team intends to spend time on—including internal work that the customer will never notice. This helps set expectations with stakeholders and other teams, especially when they bring additional work to you, and makes engineering time a fixed asset.
Once the product backlog is built, it's important to regularly maintain it to keep pace with the project outcomes and project delivery. Product owners should review the backlog before each iteration planning meeting to ensure prioritisation is correct and feedback from the last iteration has been incorporated. Regular review of the backlog is often called "backlog grooming" in agile circles (some others use the term backlog refinement).
Once the backlog gets larger, product owners need to group the backlog into near-term and long-term items. Near-term items need to be fully fleshed out before they are labelled as such. This means complete user stories have been drawn up, collaboration with design and development has been sorted out, and estimates from development have been made. Longer term items can remain a bit vague, though it's a good idea to get a rough estimate from the development team to help prioritise them. The key word here is "rough": estimates will change once the team fully understands and begins work on those longer term items.
The backlog serves as the connection between the product owner and the development team. The product owner is free to re-prioritise work in the backlog at any time due to customer feedback, refining estimates, and new requirements. Once work is in progress, though, keep changes to a minimum as they disrupt the development team and affect focus, flow, and morale.
Only entries that add value
Each entry in the Product Backlog must have some kind of customer value. Entries without any customer value are pure waste and should not be present anyway. The Scrum Product the Sprint Backlog can include entries for the exploration of customer needs or various technical options, a description of both functional and non-functional requirements, the work necessary to launch the product, and other items as well, such as setting up the environment or remediating defects. Some tasks may not add direct value to the functionality. Nevertheless they might add value by increasing quality or reducing incidents in the long term.
Living document
The Product Backlog is changed throughout the whole project. If needed, new requirements are added and existing requirements may be modified, defined in more detail or even deleted. Requirements are no longer frozen early on. Instead the final set of requirements within the Product Backlog is also developed iteratively, together with the resulting software. This is different to traditional requirements engineering but allows maximising customer value and minimises development effort.
Different level of details
The requirements in the Product Backlog have a different granularity. Only those requirements that shall be implemented during one of the next sprints are defined in greater detail and everything else is more coarse-grained. The simple reason for this is that it does not make sense to invest time and effort into the specification of these requirements, as most of these requirements will have changed anyway until implementation starts.
The Product Backlog is ordered
All entries are prioritised and the Product Backlog is ordered. The Product Owner with the help of the Scrum Team does the prioritisation. Added Value, Costs and Risks are the most common factors for prioritisation. With this prioritisation the Scrum Product Owner decides what should be done next.
All entries are estimated
All the entries within the Product Backlog have to be estimated according to the agreed definition (e.g. story points). This estimation can then be used to prioritise entries in the Product Backlog and to plan releases.
Working with the Backlog
The backlog needs regular attention and care - it needs to be managed carefully. At the start of the project the Scrum Team and its Product Owner start by writing down everything they can think of easily. This is almost always more than enough for a first sprint.
After this initial setup, the Product Backlog has to be maintained in an ongoing process that comprises the following steps:
As new items are discovered they are described and added to the list. Existing ones are changed or removed as appropriate.
Ordering the Product Backlog. The most important items are moved to the top.
Preparing the high-priority entries for the next Sprint Planning Meeting
(Re-)Estimating the entries in the Scrum Product Backlog
The Scrum Product Owner is responsible for making sure that the Scrum Product Backlog is in good shape this is a collaborative process. When using the Scrum Framework about 10% of the Scrum Teams total time should be reserved for maintaining the Scrum Product Backlog (discussion, estimation etc.).
The collaborative maintenance of the Scrum Product Backlog helps to clarify the requirements and creates a buy-in from the Scrum Team.
A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.
Working with the project backlog requires the product owner to share, prioritise and communicate. Some of the patterns of behaviour an unsuccessful product owner will show are
The product owner prioritises the backlog at the start of the project, but doesn't adjust it as feedback rolls in from developers and stakeholders.
The team limits items on the backlog to those that are customer-facing.
The backlog is kept as a document stored locally and shared infrequently, preventing interested parties from getting updates.
Savvy product owners rigorously groom their program's product backlog, making it a reliable and shareable outline of the work items for a project.
Backlogs prompt debates and choices that keep a program healthy–not everything can be top priority.
Stakeholders will challenge priorities, and that's good. Fostering discussion around what's important gets everyone's priorities in sync. These discussions foster a culture of group prioritisation ensuring everyone shares the same mind-set on the program.
The product backlog also serves as the foundation for iteration planning. All work items should be included in the backlog: user stories, bugs, design changes, technical debt, customer requests, action items from the retrospective, etc. This ensures everyone's work items are included in the overall discussion for each iteration. Team members can then make trade-offs with the product owner before starting an iteration with complete knowledge of everything that needs to be done.
TIP:
Product owners dictate the priority of work items in the backlog, while the development team dictates the velocity through the backlog. This can be a challenging balancing act for new product owners who want to "push" work to the team.