How Scrum Works
by Kelley Louie
Adding Items to a Product Backlog
The Product Backlog is a prioritized list of requested features/functionality and is owned and managed by the Product Owner. The Product Owner ensures that the most valuable functionality is delivered first and is responsible for updating and prioritizing the Product Backlog items. All items within the backlog are ranked with the highest priority items at the top and the rest following in descending order; if necessary, items may be grouped into rough priority categories, but strict rank order is preferred.
The Product Backlog is a living document; it changes whenever the Product Owner receives new information. The Product Backlog helps guide the team in selecting work that best reflects business priorities for each iteration of development. It is available to all interested parties and anyone can contribute to it through the Product Owner. The prioritization for the items on a backlog is reached through negotiations between the Product Owner and stakeholders and items are reprioritized as new business needs arise.
Most of the items that go into a Product Backlog are business driven rather than technology driven. Items may be derived from
* Business plan
* Vision statement
* Customer feedback
* Internal feedback from client services, sales, or customer support personnel
* Market analysis
* Process improvement suggestions
Technological items proposed by the development team are also added, but they must be phrased in business language to make their value clear. Anything of business value that consumes team resources should be added to the Product Backlog.
How are feature/function items listed on a Product Backlog? They are briefly described in a single spreadsheet row with a rough work estimate and any other data that the Product Owner desires. Given that most features require considerable elaboration, how can one line on a spreadsheet be enough? Each Product Backlog item represents a promise of a conversation between the Product Owner (or whoever has the additional feature detail information) and the appropriate developers. This allows the Product Backlog item to be briefly descriptive without elaborate requirements documents.
One good way of writing Product Backlog items is the “user story” technique. This is a brief description that tells a meaningful story about some user role, what someone in that role wants to be able to do, and why. User stories often have the form “As a _____, I want to ______, so that _________.” For example, “As a ScrumAlliance member, I want to read past Scrum Gathering documents, so I can learn Scrum’s fine points.” Or “As a hotel guest, I want to use an outdoor spa, so I can relax.” Mike Cohn has written extensively about user stories and their use in Scrum, and he suggested the story template above. Product Backlog items written in this way are self-explanatory, although they still represent conversations that will elicit considerable additional detail.
Along with a brief description of the desired feature/functionality, the Product Backlog contains a rough work estimate for a feature. These estimates are preliminary and are used for planning purposes only ? they are very high-level indications of feature complexity, not commitments to deliver the feature in a specific amount of work. Creating these estimates will be examined in detail in the next section.
What other data are often added to Product Backlogs? Common items include:
* Unique feature identification number
* References to additional documents that describe a feature
* Functional area of a feature within the larger product
* Source of the Product Backlog item, e.g. a specific customer
* Drag factors that may delay development and an adjusted estimate
* Defect type or severity
* Budget cost estimate
* Estimates of total business value of the feature
The important thing is that the Product Backlog contains only the information that helps the Product Owner guide the development team. What tools are used to store and edit Product Backlogs? Probably the most common is the spreadsheet, followed by the word processor and various defect tracking systems. Even whiteboards, Post-it® Notes, and paper lists are possible ways to track a Product Backlog. But specialized project management tools also exist that support Product Backlogs. These include:
The appropriate Product Backlog tool should be chosen by the ScrumMaster and Product Owner in consultation with the team, as it represents a choice about how team process should be managed.
Let’s look at two examples: A ScrumWorks Example and an Internet Example
Our company is building software to aid managing projects that use Scrum. ScrumWorks has proven to be essential for our team to implement Scrum. One feature of this tool is that it allows users to easily prioritize and add additional information for Product Backlog items.
The screenshot below illustrates part of a fully prioritized Product Backlog. Now, let’s examine this Product Backlog in more detail. The first item that was added to the Product Backlog was ‘Faster Desktop Client’. ‘Faster Desktop Client’ is simply a summary statement that the Product Owner and stakeholders understand. ‘Split Backlog Items’ was added next. It is simplest and most efficient to prioritize backlog items according to the existing Product Backlog items. The question to be asked is whether ‘Split Backlog Items’ is higher or lower in priority than ‘Faster Desktop Client’. The Product Owner and stakeholders agreed that ‘Faster Desktop Client’ is higher priority than ‘Split Backlog Items’, so it was placed in that order. ‘Team Centric’ is lower priority than ‘Faster Desktop Client’, but higher priority than ‘Split Backlog Items’. Continue prioritizing the Product Backlog items in this manner until all requirements have their own unique ranking within the Product Backlog.
Product Backlog items are not solely limited to the Product Owner and stakeholders, the team can also add requirements. For example, the team requested to re-factor the code to eliminate duplicate code and increase maintainability. The Product Owner and stakeholders prioritized ‘Eliminate Refresh Inconsistencies By Using the Same Code Base’ as any other requirement.
‘Faster Desktop Client’ is at the top of the Product Backlog. This will be one of the first features that the team tackles. The development team agrees to work on the highest prioritized Product Backlog items as determined by the Product Owner and stakeholders. This will ensure that the team works on features that the Product Owner deems important and meets the expectations of the Product Owner. The prioritization constantly changes and frequent communication with the Product Owner is needed for project progress. The Product Backlog will be re-prioritized before each Planning Meeting. With frequent feedback, all parties know and can change the direction of the project.
Prioritizing the Product Backlog forces all parties to think about the importance of each requirement. Some Product Owners will say that several features are important, but not differentiate the priorities amongst the features. A single list forces the Product Owner to focus on priorities. By maintaining a list, there are no ambiguities about the importance of each requirement.
This example is from a team wanting to build a new website channel for people with similar interests to come together and share information about their hobby. The original project has been changed slightly to protect confidentiality.
This was a ‘Greenfield’ project so they were starting from scratch to build out the main site components they needed.
The site consisted of:
* Message boards – a community forum for subscribed members
* Photo gallery – for members to trade images
* Ratings – ratings given by members
* Search – an embedded search engine optimized to search other sites and bring back relevant search results
The Product Manager had a Product Requirements Document (PRD) and the team had gone through the governance and ideation phase, he then transferred his heavy text document into a Product Backlog format. The example below shows the items chosen by the team for the first Sprint for what they felt they could deliver on within 4 weeks. The team did overcommit which is fairly typical for a new team to do. The issues that slowed them down included reviews from the web standards committee for the user interface. They bought up this issue in their retropective and worked on streamlining the process and scheduling time with the right people in advance so they wouldn’t get slowed down next time.
You can see how the stories are built around the user. These could be broken down into ‘persona’s’ relating to the different types of users, but for the first Sprint the Product Manager kept this fairly generic.
The order of backlog items chosen isn’t exactly in the 1,2,3,4 etc order that you might expect. There were dependencies on other teams that meant some items could not be tackled in the current Sprint, some items were larger than expected and the team and Product Owner negotiated the items as it made the most sense so they could complete some pieces of functional code by the end of their sprint.
Once the items were negotiated the team went on to create the Sprint Backlog.
Estimating Product Backlog Items
Product Backlog estimates provide a relative measure of the complexity of each different feature in the backlog. They serve as a guide to the team in selecting work for a Sprint, and to the Product Owner in planning a release. Estimates are made when an item is added to the Product Backlog or when an existing backlog item is substantively changed.
These estimates are not binding commitments to deliver a feature in a certain amount of work. They are educated guesses by experienced and well-informed practitioners. Considering the level of information generally available during Product Backlog estimation, these guesses are entirely sufficient for planning purposes.
Product Backlog estimates should be provided by the team that is to do the work, or a team of similar composition, with agreed upon units of measure; otherwise there is a risk that estimates will vary wildly from the Scrum team’s actual work.
There are several methods of providing these estimates, but each has two components: the units of complexity employed and the method for analyzing a feature for its complexity.
UNITS OF COMPLEXITY
* Size category
* Story points
* Work days
Size category. The simplest way to rate features is by size category: small, medium, large, extra-large. Or, as some people call this, the “T-shirt size” estimate. The key here is to agree on what these sizes mean; otherwise different estimators may rank the same feature quite differently. Small variation between estimators is to be expected ? the line between a small and a medium can be very fine, but two estimators should not rank the same feature very differently unless one has seen some complexity that the other has missed.
The team must also know how much they can take on in a Sprint and be able to trade off features of different sizes; for example, exchanging one medium-sized feature for two small ones. This is the major weakness of the size category estimates: the units of measure are categorical, not quantitative, so they can not be added up.
Story points. Another system remedies this weakness: XP’s story points are arbitrary, relative, non-dimensional units of complexity that are assigned by estimators to each feature. Again, consistent definition is the key to success: the team must agree on examples of a one-point feature, a two-point feature, and so on. But with story points, agreement is made easier by following the rule that a two-point feature should be twice as difficult as a one-point feature.
Story points thus form a linear, quantitative scale of complexity. That makes it easy for a team to trade off two “one story point” features for a single “two story point” feature during Sprint Planning. It is also easy to measure team progress in story points: in any Sprint, the number of story points successfully completed forms the team’s velocity in working through Product Backlog features. The velocity can be used by the team to select the number of story points in features undertaken in the next Sprint.
Work days. A final option is to estimate the number of work days involved in creating a feature. Most people have a shared understanding of a work day (although discussion and precise agreement on this unit’s meaning is still required). Work days are also a linear measure of complexity so feature trade-offs are easy to make. But to create estimates in work days requires a very good understanding of the feature and of the team’s abilities. This granularity of estimation also risks misleading the Product Owner and stakeholders into believing that people can be traded for features and time; this is Fred Brooks’ (1975) classic fallacy of the “mythical man-month.” Development is simply more complex than that; using work days as an estimation unit implies a precise ability to predict the nature of work required to produce a feature. Nevertheless, in some environments, using work days for Product Backlog estimates may be appropriate or even necessary. Just use them with care.
METHODS OF ESTIMATION
The simplest analysis method is the expert review. An experienced developer who knows the product domain, technology, and the team gets a quick overview of a feature and produces a rough estimate of its complexity. This technique is probably the most frequently used, but it depends wholly on the experience and skill of the estimator and their personal heuristic methods. If you get a real expert who has done this kind of work before, these estimates can be very good.
Another alternative is to draw on the more detailed estimation techniques developed in other project management methodologies.
One particularly useful method is to create a Work Breakdown Structure (WBS). This document lists the deliverable components of a Product Backlog item and then hierarchically decomposes these deliverables into more and more precise units of functionality until the tasks necessary to perform the work become clear and estimable. Other methodologies go further with a WBS, assigning task codes, workers, and building schedules from this initial analysis hierarchy; Scrum does not. Creating a partial WBS is merely a tool for better understanding the complexity of a feature and putting a complexity measure to it.
Probably the best way to create a WBS is simply to use sticky notes on a wall. Create a single sticky note for the Product Backlog item and stick it high in the center of a blank wall. Then create one note for each high-level part of that feature and arrange these horizontally underneath that one note, widely spaced apart. Repeat this decomposition process for each of the notes on the wall until the complexity of each sticky note (in your chosen units of complexity) becomes clear and can be estimated.
If a size category (T-shirt size) measure of complexity is being used, simply the number of sticky notes in the WBS tree may be sufficient to categorize a feature’s complexity.
If a linear measure of complexity has been chosen, then the lowest level of sticky notes can be assigned complexity values, and these complexities summed up the tree to create the complexity for the entire feature. This is especially valuable when using working days as a metric.
You can use any feature analysis method that you prefer, as long as it is not excessively detailed and does not require too much time. The idea is to rapidly produce a rough estimate that is good enough for strategic planning, but one that should not give the illusion of being definitive.
REFINING PRODUCT BACKLOG ESTIMATES
For example, if a particular feature will require working with a specialist who is not co-located with the general development team, this feature should have its estimate increased by 20%. Such drag factors increase the amount of effort a feature will require. The values for these drag factors are heuristics and are spelled out in detail in the Scrum Methodology document.
Providing rough estimates of Product Backlog items enables the Product Owner to evaluate the effort involved in a release and allows Team Members to select backlog items appropriately for a Sprint. Many estimation methods are available, both in terms of estimation granularity and analytical technique; choose the one that best fits your circumstances. Let’s look at an example.
Scrum Works Example
There is sometimes a temptation to be overly precise about estimating backlog items. For example, in the past our team would sometimes get overly analytical by estimating backlog items in units of ideal engineering hours. Backlog estimation occurs outside of the sprint typically, and because Scrum is an iterative process, detailed analysis should be conducted inside a sprint instead. Too much detail up front can cause an over-reliance on estimation accuracy as well as analysis paralysis.
To combat this tendency, our team time-boxes backlog item estimation to just a few hours per sprint. The team is forced to get through the entire backlog before time is up. This entails the estimation of new backlog items and re-estimation of items already on the backlog.
We also use a very high-level, ambiguous unit for the estimation of backlog items, magnitude “points”. Magnitude points are simply a rough sizing of the backlog items. We use a scale of 1 (smallest) through 5 (largest) when estimating high-priority, well decomposed backlog items. Lower priority backlog items are typically larger for ease of prioritization and can therefore have larger magnitudes (10, 20, 30, 40, etc.).
For example, the team estimated that ëFaster Desktop Clientí would take 40 backlog units, while ëTeam Centricí would require 30 backlog units. How does the team arrive at these numbers? First, the team assesses the work and then compares the estimate to other Product Backlog itemsí estimates. The estimate was based on the team’s domain knowledge and the complexity of the work. This system works “well enough” for our team, and your team may develop it’s own system for applying backlog estimates. In the end, how backlog items are estimated is not of concern so long as the system is applied uniformly.
For example, our team has an established velocity of 65 points. This means that for any given sprint the team can take on work totaling roughly 65 backlog effort points, so long as the team composition and project domain are stable.
Updating the Product Backlog
The Product Backlog is updated frequently over each iteration of the Scrum project management cycle. Typical changes for each part of the cycle are described below.
Pre-project/Kickoff Meeting. Before the project begins, an initial Product Backlog is created, prioritized, and estimated. This drives the initial Sprint of the project while more Product Backlog items are developed.
Sprint Planning Meeting. During each Sprint Planning Meeting, the development team selects items for the Sprint. These items are then frozen in the Product Backlog by the Product Owner and are not changed for the duration of the Sprint.
Sprint. During the Sprint, the team works on developing the features selected and frozen in the Product Backlog. The rest of the Product Backlog is completely free to change in response to new business knowledge, customer requests, and other information.
One common change to the Product Backlog undertaken by the Product Owner during each Sprint is the refinement and elaboration of Product Backlog items as they come closer to being implemented by the team. Initial descriptions of features may begin quite vague, and estimates very rough, but as features move up in priority, they need to be described in greater detail. In the case of a Product Backlog built from user requirements, less precise requirements often need to be replaced by several more detailed ones, and these new requirements need to be estimated. This insures that Product Backlog items have reached the appropriate level of detail by the time they are selected by the team for a Sprint.
Sprint Review Meeting/Sprint Retrospective. After an increment of functionality has been presented by the team and the Sprint process reflected on, any new features/functionality revealed need to be captured in the Product Backlog. These may be portions of features that were not completed in the Sprint, or new ideas surfaced by reaction to the work produced. It may include team process improvements revealed by the Sprint Retrospective. All this is crucial feedback that needs to be incorporated into the planning process, and so must be captured in the Product Backlog and prioritized before the next Sprint Planning Meeting.
These steps insure that the Product Backlog provides a useful guide to steer the development team as they proceed forward with the project. Let’s look at an example using Scrum Works.
Scrum Works Example
Projects evolve and the project backlog must be updated to reflect the new state of the project. New work can not be added to a sprint, but it can be added to the project backlog as work to be prioritized and estimated. The Product Owner should be updating the product backlog with the latest changes: additional features and prioritization. The team should spend some time during the sprint to break down the top priority backlog items so they will be the appropriate size to tackle within a sprint. The team breaks up a product backlog if it is too big and can not be completed within a sprint. At this time, all high priority backlog items’ estimates are revised by the team as needed. Product backlog items with low priorities will not be in the next sprint and will likely change. Low priority backlog itemsí estimates only need high-level estimates until it is expected to be added to a sprint. Our team re-estimates the product backlog the day before the sprint review with the Product Owner’s go-ahead. This ensures that the Product Owner has had enough time during the sprint to add update the product backlog.
Product backlog items not fully implemented and robustness issues are usually added at the end of the sprint. Typically, the Product Owner sees the work and requests changes to the work just completed. It is the I’ll know it when I see it–fact of life. Once the Product Owner can touch and feel the software, he/she knows whether or not it has met his expectations and make adjustments accordingly.
Imagine Product Backlog #1 created before the sprint review and Product Backlog #2 updated after the sprint review meeting. Faster Desktop Client was a feature that is not atomic. There are different functionalities that will support a faster client. The team split this backlog item into the following: Faster Backlog Window, Faster Sprint Detail Window, and Faster Impediments Window. This breakup clarifies the work for the Product Owner’s prioritization and for the team when it is added to a sprint. On the other hand, Team Centric was an atomic feature that could fit into a sprint. There was no good reason to split it. The team did not revise any estimates because they considered the estimates to be correct.
After the sprint review meeting, the product backlog changed. The Product Owner realized that the Product Burndown chart presented by the team would be more user-friendly with some enhancements. This was added to the product backlog as the top priority.
Based on the updated product backlog, the team and Product Owner are both prepared for the planning meeting. The team can tackle the highest prioritized backlog items because the backlog was maintained by both the Product Owner and team. Constantly updating product backlog is an integral part of empirical process.
Release Burndown Charts
Release Burndown charts form a visible means of tracking feature completion against a goal such as return on investment or a fixed date. Given a specific set of features designated for a release, the Product Owner can track the estimated number of work units remaining until release, Sprint by Sprint.
This provides a graphic indication of progress or lacks towards completing the sprint tasks to upper management for a given sprint.
Simple trend analysis can indicate if the release is on target or if corrective action needs to be taken to meet business goals.
If features are added, changed, or removed from a release, the Release Burndown chart should be updated to reflect these changes and indicate a new estimated date of completion. This can happen automatically in some tools (even Excel). In some instances the features added exceed the velocity of the team and the trend line trends upward rather than downwards, reflecting a severe “desire” disorder.
Thus Release Burndown charts provide a visual, visceral indication of the progress of a Scrum team from a long-term business perspective. Take the following examples: Combined product/work breakdown structure and Scrum Works.
Combined Product/Work Breakdown Structure
The following combined Product / Work Breakdown Structure / Sprint Burndown is used for tracking progress in a large scale Scrum project for social security agencies in Switzerland.
The chart shows a product burndown line tracing the overall volume of requirements in ideal engineering days (IED). As can be seen this line is not going downwards, but is fluctuating slightly at a quite high level. This is because this chart shows the start of Scrum usage in the project in August of 2004. From previously done work, there is already quite a big backlog of known requirements, but still at a very rough granularity. At the same time as the development team was implementing further analysis was going on, so new requirements were still added.
The AP1 burndown curve instead shows one category of the work breakdown structure (WBS) used in the project to subdivide the work volume into smaller chunks alongside functional boundaries. These are also the demarcation lines along which work naturally was broken up among multiple teams (that were formed just recently). There is a clear trend visible of progress for the AP1 grouping of work.
The same can be said for the Sprint Burndown curve (the name of the Sprint being its end date, the end of the month actually). The team was able to accomplish 94 IEDs out of 99 projected. Only 5 IEDs remained in the backlog and had to be put back into the product backlog, to be prioritized again with the other requirements to be done.
Interestingly the Sprint Burndown delta does not quite match the AP1 burndown delta. This is because during development some of the requirements were dropped by the customer and partially resolved more quickly than anticipated.
Scrum Works Example
The team has discovered that Mike Cohn’s enhanced burndown chart was the most helpful chart. This chart easily and quickly projects the completion date and demonstrates the amount of work completed and the amount of work added during a sprint. The first sprint started with 380 backlog effort. The team finished 180 backlog effort which is shown by the decrease from bar 1 to bar 2 above the 0 baseline. During the sprint, 20 backlog effort was added which is represented by the blue bar below the 0 baseline. Therefore in the second sprint the team has a total of 220 backlog effort for the remainder of the project. The new baseline is moved to the bottom of the bar for each sprint.
With this information, trend lines based on work completed and work added can be extrapolated to predict a possible completion date. The red trend line is based on the backlog effort completed per sprint. The blue trend line tracks the amount of work added during the sprints. Based on this chart, if no new work is added, the project is completed. If work is added at the historical rate, the project will end in 3 sprints.
Change will always occur and this chart demonstrates their affect on the project schedule. If new work is added at a faster rate than work completion, the project will continue without an end. Vice versa is true too. If the team works faster than the amount of work added, the project will complete earlier than expected. Comparing velocity to the amount of new work will present a more accurate picture of project progress.