One of the most important artifacts in the Scrum Framework is the Product Backlog. Like the other artifacts, its purpose is to make something transparent and clear. It is managed and maintained by the Product Owner, and its purpose is to make clear the plan for developing a product and the sequence in which the product’s features and functions are to be created.
The Definitive “Wish List” for a Product
Every product that exists has some kind of list of future enhancements that may or may not be made to it, depending on present and future business conditions. Sometimes this document is referred to as a product road map . Sometimes it is called a comprehensive release plan . In the Scrum Framework, it is referred to as a Product Backlog.
Unlike traditional road maps and release plans, the Product Backlog contains only descriptions of enhancements and an indication of their priority for development. It does not attempt to schedule the delivery of these features and enhancements in any way.
There are no due dates attached to Product Backlog items (PBIs) . There are only business priorities. The assumption is that higher priority items will be completed and delivered before lower priority items are addressed. The schedule for delivery of PBIs is not set, but the anticipated sequence of delivery is.
Product Backlogs exist as long as their products do. The first step to take when creating a new product is to create its Product Backlog. This is done by writing down a list of the features the new product will have. After the first version of the product is developed and released, new additions and enhancements may be gathered in the Product Backlog to be created for future versions. Work continues in this way until the product reaches the end of its life. The Product Backlog is finally closed out when enhancing the product no longer makes any sense from a business point of view.
It goes without saying that any product should have only one set of priorities for its development. If there are several lists of priorities managed by different people, the result is chaos. A product may have only one Product Backlog, and a Product Backlog may contain only the priorities for the development of a single product.
Likewise, any product should have one and only one person who is accountable for its business success. That person is the one who should make decisions about the features the product should have and choose which features are the most important to develop first.
The Scrum Framework vests responsibility for the Product Backlog with the Product Owner. Product Owners are the ones who may add, change, or delete items in the Product Backlog. The Product Owner is the only person who may set priorities for the items in the Product Backlog.
When a Development Team does its work, it always works from the Product Backlog of a particular product. Each Development Team must work from only one set of priorities, so it may work on only one product and with one product owner at a time.
In addition, if Product Owners are to be accountable for the value the Development Team delivers, they must control the scope of work the Development Team undertakes. For this reason, developers are only allowed to work on items that appear in the Product Backlog and must respect the priorities set by the Product Owner.
A Product Backlog is a repository for all the additions, changes, and enhancements that are planned to be made for a product over time. It contains descriptions of each change and it is owned and maintained by the Product Owner. The items in the Product Backlog are sequenced by the Product Owner according to their importance in delivering value. At any given time, the Product Backlog contains the entire development plan for a product as it is known at that time.
The Product Backlog is the source of the Product Owner’s authority. A Product Owner is accountable for the business value produced and delivered by the Scrum Team, so the Product Owner must control the list of changes and enhancements the team may produce. In the Scrum Framework, the Development Team may work only on items that appear in the Product Backlog. The Product Backlog may only be added to or changed by the Product Owner. Thus the Product Owner controls the changes that may be made to a product and can be held accountable for choices made about them.
Each PBI is a description of some content, feature, or function of the product as seen from the consumer’s point of view. Each item must be a partial answer to the question: What should the product do? It should describe some feature, function, or characteristic that will add to the value of the product when completed. It should also describe something that can be demonstrated as complete and working when work on the item has been finished.
The items in a Product Backlog should represent problems to be solved as opposed to tasks to be performed. For example, a useful PBI might be “There needs to be a way for users to log in” as opposed to “Create a user login screen.” Creating a screen limits the developers’ options for filling the need. Solving the problem of providing a way to log in allows developers to explore many technical options, such at third-party login (e.g., log in with Google) or even biometric identification (using the fingerprint reader available on most smartphones). The Product Backlog should strive to be very clear on the need to be filled, and lets the developers come up with their own strategies for filling the needs.
A product may have one and only one Product Backlog. There must be one and only one plan for the development of the product, one set of goals, and one set of priorities. If there are multiple plans with conflicting priorities, the result is chaos.
A product may have one and only one Product Owner. If more than one person is accountable for the value of a product, then no one is accountable for the value of that product.
The “User Story” Form
“As a [person] I want to [action] so that [reason].”,
where [person] is someone who is involved, [action] is some feature of the product, and [reason] speaks to the need the person sees and knows needs filling.
As an administrator , I wish to reset passwords so that the customers can log in easily without becoming frustrated,
the person is an administrator. Among other things, it can be assumed that the function is for someone who has knowledge about and experience working with the product.
The action is to reset passwords.
The reason is to prevent frustration on the part of customers. They want to be identified to the system and to have access to their private information. They do not want to fight through a difficult and complicated identification and verification process.
Acceptance Criteria
The user story form is very useful for describing the general problem to be solved. Most often, though, the user story must be supplemented by adding specifics needs to it. These needs take the form of acceptance criteria. These criteria specify specific tests that must be passed before the implementation of the user story solution is deemed “acceptable.”
User stories themselves tend to describe the behavior of the product when all goes well. The story “As an account holder, I want to change my login credentials from time to time so that they become harder to guess by an intruder” describes a positive need that can be fulfilled in a number of ways. It describes the so-called happy path scenario.
Most often, this happy path scenario needs to be qualified with instructions about what to do when all does not go well. What should be done, for instance, when users try to change their credentials to “blank?” What if they change their credentials to a value they used previously? What if they change their password to “password?”
Acceptance criteria provide a way to qualify a user story so that the “happy path” is accompanied by an appropriate number of negative scenarios that describe its function further.
If I try to change the credentials to “blank,” I should see an error message that says “blank” credentials are not allowed. I should be asked to try again.
If I try to change the credentials to a word in the Oxford English Dictionary, I should see an error message that says dictionary words are too easy to guess and are not allowed. I should be asked to try again.
If I try to change the credentials back to a value I used within the past four changes, I should see an error message that says recent passwords are not allowed. I should be asked to try again.
When specified well, these acceptance criteria serve two valuable purposes. First, they guide the developers on the team to create functionality that takes these “negative scenarios” into account. Second, they form the basis of the acceptance tests needed to validate the proper working of the new functions. This combination of effects has led to a codification of the practice. It is called acceptance test-driven development, or ATDD for short. It is one of the families of practices that are collectively known as Extreme programming.
Other Forms: Behavior-Driven Development
The user story form is not the only template for describing functionality in the product backlog. Another syntax that is gaining popularity is known as the behavior-driven development (BDD) form. This form attempts to describe the behavior desired and the contexts in which that behavior is required.
Given that users wish to change their password
Given that users have used the password “123xyz@@” as one of their prior four passwords
When the users attempt to change their password to “123xyz@@”
Then a message should be shown that says duplicated passwords are not allowed
Then users should be given another chance to change the password
In this form, the given statements set the contexts, the when statements specify the action, and the then statements describe the results.
The BDD form not only describes functionality in a way that is straightforward for developers to implement, but also it lends itself to the automation of the acceptance testing effort. BDD is often used in conjunction with a tool called Cucumber. Cucumber reads BDD form requirements (called gherkins ) and translates them into “unit test” calls using tools such as J-Unit. The result is a combination of high-level requirements written in a language understandable to nontechnical people, and low-level testing that is conducted directly from these requirements. The approach is gaining popularity.
The Product Backlog as a Forecasting Tool
Traditional product road maps are often used to define schedules and deadlines. The theory of Empirical Process Control maintains that predictions of future events are inherently inaccurate and can lead to bad outcomes. For that reason, the Product Backlog contains no deadlines. It does not define any kind of fixed schedule for the development of the product.
Although Empirical Process Control states it is impossible to predict what will happen by a given point in time, it is possible to get an idea of what is likely to happen by a given point in time. The Product Backlog can be combined with measurements of actual activity to provide forecasts for the development of the product.
Let’s assume there is a Product Backlog containing 100 items of equal size. Let’s also assume that a Development Team has been working on the backlog and has been able to complete roughly five items per sprint. It is impossible to say exactly when the 100th item will be completed by the team, but based on what we know now and based on the measured capacity of the team, we can forecast that the 100th item will be completed 20 sprints from now.
It is important to stress the inherent uncertainty about future events whenever one is asked to make predictions about them. Making predictions is risky because predictions often imply a degree of precision and certainty where none is warranted.
There are two important qualifiers that should always be used: based on what we know now and based on the measured capacity of the team.
What do we know now? We know what the unfinished items on the Product Backlog are. We can make a forecast based on what they are at the moment, but the fact is that the Product Backlog can change at any time. The Product Backlog on Tuesday may look quite different from the Product Backlog on Monday. The content of the Product Backlog depends on the ongoing process of discovery that the Scrum Framework facilitates. Any forecast is uncertain because the content of the Product Backlog itself is uncertain.
What is the “measured capacity of the team?” It is the average amount of work the team accomplishes each sprint, measured according to the size of the PBIs it completes. If a team has completed an average of five PBIs per sprint in the past, its capacity is described as “five PBIs per sprint.” This capacity (also known as velocity) tends to remain fairly constant as long as the makeup of the team does not change.
Teams do change, though. People leave to get their dream jobs elsewhere. New people join with the hope of obtaining more and better experience. The measured velocity of a team last month may have no relevance to the team that exists now.
The Product Backlog does not provide the imagined certainty of a fixed schedule. It does, however, provide a realistic forecast of what is likely to happen and when it is likely to take place. These forecasts can be used to plan actions that are dependent on the accomplishment of certain milestones. It is not possible to know exactly when milestones will be achieved ahead of time. Using the information provided by the Product Backlog and the team’s velocity measurements, it is possible to make a pretty good guess.
The Product Backlog as a Status Reporting Tool
The Product Backlog’s purpose is to provide transparency. It is often referred to as an information radiator that provides important facts to whoever examines it.
What is being worked on now?
When will the current work be finished?
What is next?
When will that be finished?
And so on.
The Product Backlog provides all this information—to the extent that this information can be known at any given point in time.
Does the Product Backlog tell us what is being worked on now? The answer is yes. The PBIs that have been accepted into the current sprint are what is being worked on now.
Do we know when the current set of PBIs is to be completed? The answer is yes. They are to be completed by the end of the current sprint.
Do we know what is next? The answer is probably. Using the Product Backlog and the team’s velocity, we can make a forecast as to which items will be “next.”
Do we know when the next items will be complete? The answer is yes. Whatever the next items are, they should be complete by the end of the next sprint.
And so on.
Summary
A complete list of all the product’s features and functions as the Product Owner understands them as of that moment
A ranking of the importance of those features and functions, which serves as a rough sequence for when they will be implemented
A forecast timeline for the development of the product based on the current contents of the Product Backlog and the current measured capacity of the Development Team to implement the items in the Product Backlog
Information about what is being worked on at the moment and when it is expected to be completed
The Product Backlog is a single artifact that replaces many other traditional ones used in other frameworks. It is simple, elegant, and effective.