Chapter 5

The Product Backlog

The Product Backlog is an ordered list of everything that might be required of the product. It is the single source listing all requirements for any changes to be made to the product. It includes features to be added, changes to be made, and bugs to be fixed. Each item in the Product Backlog is called a Product Backlog item (PBI). PBIs can range from extremely important and urgent to quite trivial.

The Product Owner is responsible for the Product Backlog, but they may have others create and update its items. However, it is the Product Owner’s responsibility to ensure that the items in the Product Backlog are clearly defined, understood by everyone, assigned a business value, and ordered (prioritized) correctly. The Developers collaborate with the Product Owner and other stakeholders (such as domain experts) as needed during Product Backlog refinement, Sprint Planning, and the Sprint Review to understand and size the items in the Product Backlog.

This chapter will focus on how to use Azure Boards to create and refine a Product Backlog. You will also see how to foster a healthy Product Backlog, how it can enable forecasting and release planning, and how to do so using these tools. If you are more interested in the concept of the Product Backlog and less on how to use Azure Boards to interact with it, you may want to reread Chapter 1, “Professional Scrum.”

Note In this chapter, I am using the customized Professional Scrum process, not the out-of-the-box Scrum process. Please refer to Chapter 3, “Azure Boards,” for information on this custom process and how to create it for yourself.

Creating the Product Backlog

You create the Product Backlog by adding work items—one at a time or in bulk. In the default Scrum process, both PBI and Bug work item types appear in the backlog. In the custom Professional Scrum process, I have disabled the Bug work item type.

By default, only a title is needed in order to save a new work item to the Product Backlog. The Product Owner will probably require more information to assign the item a business value and order it in relation to other items. The Developers will definitely need more information than just a title to be able to size it and ensure that it is ready for Sprint Planning and development. Having a title is a good start, though.

According to the Scrum Guide, the Product Owner is responsible for the Product Backlog. This doesn’t necessarily mean that they are the one doing the actual data entry. It just means that the Product Owner is responsible for ensuring that each PBI is clearly defined and understandable. In Chapter 3, I demonstrated that, in Azure Boards, anybody with the appropriate permission can create work items. A Project Administrator can assign these permissions in Project Settings.

As stated previously, I feel that everyone on the Scrum Team should be able to contribute to the Product Backlog—at a minimum. The Product Owner may also want other stakeholders, such as business analysts, customers, or the users themselves, to be able to create work items. Why not? The fewer people in the conversation, the less diluted the story will be. That said, if someone other than the Product Owner creates a work item, a conversation should take place so that person can explain its context, purpose, and business value. If possible, this conversation should take place face to face or over the phone, and not using the discussion tools.

When someone creates a PBI, they should focus on its value (the “what”) and avoid descriptions of “how” it should be developed. When it comes time, the Product Owner can order the Product Backlog based on each item’s value, risk, priority, dependency, learning, necessity, votes, or any other criteria the Product Owner desires.

The Product Backlog can emerge and evolve quickly if the business requirements of the product and other conditions change. To minimize waste, detailed requirements should be avoided except for the highest-ordered items (the ones at the top of the backlog). Even then, only enough details are required in order to size the item. The teams that I have worked with preferred having two to three Sprints’ worth of refined PBIs at the top of their Product Backlog.

Smell It’s a smell when I see tasks, tests, impediments, statements, gripes, or guidance in a Product Backlog. What I’m talking about is a PBI titled, “We should back up the database each night” or “Find a better place to meet for our Daily Scrum.” The Product Backlog should contain only items that represent a potential change in the product being developed. This is not to say that a valid PBI couldn’t have some goals, guidance, or gripes attached to it.

Creating a Product Backlog in Azure Boards

As previously mentioned, Azure Boards is just one of the services in Azure DevOps. Azure Boards is the service that provides the planning, tracking, visualizing, and managing of work. Using Azure Boards, a Scrum Team can manage backlogs at several levels (such as Epics, Features, and Stories). Developers can also plan their Sprints and create their Sprint plan by using the Sprint Backlog and related Taskboard.

Azure Boards enables a Scrum Team to perform the following Product Backlog–related activities:

• ■   Add items to the Product Backlog.

• ■   Import items into the Product Backlog.

• ■   Establish hierarchical backlogs of Feature work items.

• ■   Map PBI work items to Feature work items.

• ■   Establish hierarchical backlogs of Epic work items.

• ■   Map Feature work items to Epic work items.

• ■   Report bugs.

• ■   Manage and refine items in the Product Backlog.

• ■   “Bulk-modify” items in the Product Backlog.

• ■   Reorder the Product Backlog.

• ■   Calculate velocity to be used for forecasting.

• ■   Forecast how many PBIs might be deliverable in upcoming Sprints (also known as release planning).

• ■   Track progress using the burndown, burnup, and other analytics.

• ■   Move undone PBIs from a Sprint back to the Product Backlog.

• ■   Calculate flow metrics such as CFD (Cumulative Flow Diagram), cycle time, and lead time. I will cover flow metrics in Chapter 9, “Improving Flow.”

A Scrum Team typically uses the Backlogs page to add and manage PBIs. The Boards page will work as well, but it is better suited for teams practicing Kanban. You can use queries, Microsoft Excel, or other client applications to manage the backlogs, but the Backlog page should be the Scrum Team’s primary UI for managing the backlog. Regardless of how it’s created and managed, the ordered (prioritized) list of work items in the Product Backlog represents the vision, Product Goal(s), and release plan (roadmap) for the software product. It is the single source of truth.

Tip Although you can add, view, and edit work items with the (free) Stakeholder access, I recommend that anyone who contributes to the Product Backlog have Basic access. Stakeholders can’t change the backlog priority order, can’t assign items to an iteration, and can’t use the Mapping pane or the Forecasting tool. On the Boards page, Stakeholders can’t add work items or update fields displayed on cards, although they can drag and drop work items to update status. Basic access provides full access to all backlog and Sprint Planning tools.

When you view the Product Backlog, only New, Ready, and Forecasted PBI work items are displayed. Done and Removed PBIs are not displayed. You would need to create and run a work item query or use the search feature to find Done and Removed PBIs. PBI work items in the Forecasted state and assigned to a Sprint are also not displayed in the Product Backlog by default. You would need to enable the In Progress Items display option, or go to the respective Sprint Backlog, to see those PBIs. This setting is meant to keep the Product Backlog lean by removing excess noise.

If your organization has multiple Scrum Teams working on a single product, then you are in a scaling situation and should consider using the Nexus Scaled Scrum framework. When Azure Boards is configured for multiple teams, you will see only those PBI work items assigned to the area path(s) specified as belonging to your team. For example, let’s assume there is a team Red that owns areas R1, R2, and R3 and a team Blue that owns areas B1 and B2. If a user on team Red changes the area of one of their PBIs to B1, it will disappear from their Product Backlog and appear on team Blue’s Product Backlog. The team Red user would need to use the search feature or create a custom query to locate that work item in the future. Members of the Default team will, by default, see all items in the Product Backlog. I will dive deeper into scaling and how Azure Boards supports multiple teams in Chapter 11, “Scaled Professional Scrum.”

Keyboard Shortcuts

Microsoft provides several time-saving keyboard shortcuts to quickly navigate within the Boards hub and manage work items. Shortcuts work with either lowercase or uppercase, as long as the focus is not on an input control. Shortcuts can be disabled as well if they become bothersome. At any time, from any screen, you can press the question mark on your keyboard to display the list of global and page-specific shortcuts. Table 5-1 lists the keyboard shortcuts that a Professional Scrum Team might be interested in.

TABLE 5-1 Azure DevOps keyboard shortcuts.

Scope	Shortcut	Description
General and project navigation	[g][h]	Goes to the organization home page (list of projects)
	[g][w]	Goes to the Boards hub
	[g][c]	Goes to the Repos hub
	[g][b]	Goes to the Pipelines hub
	[g][t]	Goes to the Test Plans hub
	[g][s]	Goes to the Settings page
	[s]	Goes to search
Boards hub	[w]	Opens the Work Items page
	[l]	Opens the Backlogs page
	[b]	Opens the Boards page
	[i]	Opens the Sprints page
	[q]	Opens the Queries page
	[z]	Toggles full screen
Backlogs page	Ctrl+Shift+F	Filters results
	Ctrl+Home	Moves the PBI to top
	[m][b]	Removes the PBI from a Sprint (set its Iteration to the root)
	[m][i]	Moves the PBI to the current Sprint
	[m][n]	Moves the PBI to the next Sprint
	[ins]	Adds a child task
	[del]	Deletes the PBI

Azure DevOps also offers page-specific shortcuts for Boards, Repos, Pipelines, Test Plans, Artifacts, and the wiki. Page-specific shortcuts only work when on that specific page.

Adding Product Backlog Items

In Azure Boards, each backlog allows you to add a new work item. This is a quick way of adding a PBI to the Product Backlog (or to the Stories backlog if you’re using the custom Professional Scrum process). The same capability exists in the Features and Epics backlogs as well. You can add the new item just above the current selection, to the top of the backlog, or to the bottom of the backlog. You can see these options in Figure 5-1. This method is fast, because you only have to provide a title, which you should keep short and meaningful. This approach allows you to quickly add several items in rapid succession, which can be helpful during Sprint Review, when feedback and ideas are flying about the room.

FIGURE 5-1 You can quickly add a PBI to the Product Backlog in Azure Boards.

Tip Clicking the Add button without specifying a title will open the work item form. This time-saving trick allows you to specify more than just the title when adding a PBI to the Product Backlog.

Besides the title, the rest of the fields will be assigned their default values, some of which might need to be changed right away, such as the Assigned To field. Most Scrum Teams like to assign PBI work items to the Product Owner, since they are the owner of that item. It is blank (unassigned) by default, which is also a valid choice. Over time, more details about the PBI will emerge, such as its area, description, value, acceptance criteria, and size. Some of these details may be known at the time of creation. Others may never materialize, especially if the Product Owner decides the item has no value. There are many ways to open a work item, but the easiest—if you are on the Backlogs page—is to just click its title.

Smell It's a smell when I see a PBI work item assigned to a team member and not to the Product Owner. This suggests that either (a) the team doesn’t understand Scrum and its beautiful separation of the “what” from the “how” across the roles, or (b) the team isn’t working as a team, and that individual plans on “owning” that item and doing all of the work to develop it.

Even if the PBI work item is assigned to the Product Owner, the smell can resurface in the Sprint Backlog if a forecasted PBI work item’s Assigned To field changes to an individual team member to indicate who is working on it. In Professional Scrum, the team should be working on the PBI, not any individual. Individuals may work on tasks associated with the PBI but leave the PBI assigned to the Product Owner throughout its lifecycle, or simply leave it blank.

In a future version of Azure DevOps, I’d like to be able to specify more information about the Scrum Team specifically. I’d like to be able to indicate which team member is the Product Owner and which team member is the Scrum Master. By doing this, Azure Boards could auto-assign PBI work items to the Product Owner, and maybe even auto-assign Impediment work items to the Scrum Master. I hope this is on Microsoft’s backlog, but if not, then maybe you could add it for me. Just visit https://developercommunity.visualstudio.com, select Azure DevOps Services, select Suggest A Feature, and add a feature idea.

If you find that a PBI work item’s Iteration defaults to the current Sprint (such as Fabrikam\Sprint 1), it means that your team’s Default iteration is set to @CurrentIteration or a specific iteration. You should change this by navigating to Project > Settings > Team Configuration > Iterations, and change the Default iteration to the root iteration (such as Fabrikam). This way, all PBI work items will be added to the Product Backlog without being assigned to any particular Sprint.

Fabrikam Fiber Case Study

Since the Product Backlog contains only PBI work items, Paula has decided to remove the Work Item Type column. She also removed the Value Area column knowing that, in Scrum, there is only business value, which is to say value as perceived by the stakeholders. She then added the Area Path and Business Value fields. This minimal set of columns allows her to focus on the basics, including ROI (BV/Effort).

The initial placement of a PBI on the Product Backlog is determined according to where you have added the item or moved the item on the page. A PBI’s position in the Product Backlog is tracked behind the scenes in the Backlog Priority field (or in the Stack Rank field in the Agile and Capability Maturity Model Integration [CMMI] processes). As you add items or drag and drop items within the Product Backlog, a background process updates that field, which is used by Azure Boards to track the order of items on the backlog. By default, this field doesn’t appear on the work item form.

These hidden numbers are not simply 1..n, but large integers with large gaps between them. Also, these gaps are not computed by halving logic, which can lead to problems if several items are added in one location (like at the top) at a time. Instead, the gaps are computed through optimized sparsification logic, which starts with the current item and “walks” up or down until it finds a gap. All the items in that range are then redistributed to create gaps for new backlog items without affecting others. If you are curious, you can view the Backlog Priority column and inspect those integers and gaps.

If you add a new PBI at the top of the backlog, its Backlog Priority will be lower than the item in row #2. If you add a new PBI at the bottom of the backlog, its Backlog Priority will be higher than the item in the second-to-last row. If you add a PBI through the Work Items page or an external client, such as Excel or Visual Studio, or via the REST API, the Backlog Priority column will be empty. PBI work items without a Backlog Priority appear at the bottom of the Product Backlog, as you can see in Figure 5-2.

FIGURE 5-2 PBIs added outside the Backlogs page won’t have a Backlog Priority.

Simply adding a new item to the bottom of the Product Backlog will cause the sparsifier—the logic that performs sparsification—to run and assign Backlog Priority values to those other PBIs. Also, a Backlog Priority will be assigned if you drag one of the new items or drag another item to the bottom.

Tip Don’t try to manually manipulate the Backlog Priority field. If you set it through Microsoft Excel, once you add or reorder the items in the backlog, the sparsification logic kicks in and sets the values to big numbers to introduce big gaps. This is by design—to improve performance. The Backlog Priority field was always intended to be a system field, and Microsoft’s recommendation is to not update it directly. So, if you want to use Excel to set Backlog Priority, avoid the losing fight with the sparsifier and use the Backlogs page instead.

If you are curious, you can see the Backlog Priority field value changes made by the sparsifier. Simply select the History tab when you edit the work item and review the changes. You can compare the current value with the previous value, as shown in Figure 5-3.

FIGURE 5-3 Work item history shows the current and previous Backlog Priority values.

Since the Product Backlog order is persisted in a static field, other lists and queries can use it. For example, when the Developers forecast PBIs for a Sprint and then view the forecast in the Sprint Backlog, the PBIs will display in the same order. This is good, because if the Product Owner has signaled that the Two factor authentication is the most important item in the Product Backlog, then the team should see it at the top of the Sprint Backlog and consider executing its work first.

Note Each time you drag a PBI in the Product Backlog, history is generated—and not just for that one item. Be mindful of this as you order the backlog.

Handling Epic PBIs

An epic PBI is any PBI that is too large to be completed in a single Sprint. For example, if the Developers have a velocity of 18 points, they should not forecast a PBI that is 21 points. Even if the Developers are not using velocity as a forecasting tool, they should never take on more work than they feel they can accomplish in a Sprint. In either case, the PBI is an epic and must be split—preferably vertically (by acceptance criteria) and not horizontally (by technology layer). Suffice it to say that splitting a PBI is a combination of science, art, magic, and a bit of luck at times.

I want to take a step back and differentiate epic PBIs from Epic work items found in the Epics backlog. When I say “epic PBI,” I’m using the term “epic” as the agile community uses it, not the way Microsoft does. An epic PBI is a generic term for a large PBI, as opposed to Epic work items, which are at the top of the hierarchical backlog of work items, sitting above Features. An Epic work item can certainly hold an epic PBI, but it might be that a Feature work item would be a better container. It just depends on how epic the epic PBI is!

Speaking of epics and features, not all organizations and teams create their top-level Epic work items in the Epics backlog and then create associated, medium-level Feature work items in the Features backlog, and then the associated, lowest-level PBI work items in the Stories backlog. Even though it seems logical to plan work this way, no organization or team typically does it like that. In practice, PBI work items often get added to the (lowest-level) Stories backlog. During refinement, if the team realizes that a PBI is, in fact, a very large piece of work (also known as an epic PBI), they can either split it into two or more, smaller PBIs or “promote” the PBI to a Feature work item and then split it into two or more smaller PBIs.

Smell It’s a smell when I see an epic PBI near the top of an ordered Product Backlog. It’s not ready for Sprint Planning. It should be split into smaller PBIs well in advance of the Sprint in which it is forecasted to be developed.

In addition to splitting the epic into two or more PBIs, the Product Owner should decide if a parent Feature work item should be created in the Features backlog and linked to the new PBIs in order to establish a hierarchy. Let’s assume that you have an epic PBI to “Improve mobile UX,” as shown in Figure 5-4. UX stands for user experience. Since this PBI’s size is larger than our velocity of 18, it must be split.

FIGURE 5-4 Epic PBIs are ones that are too large to forecast and develop in a Sprint.

First, you must split the epic PBI into two or more PBIs. Each of these would be of a smaller size (effort)—achievable in a single Sprint. Ideally, you’d want the titles to maintain some logical reference to each other, as well as the original epic PBI. For example, the epic PBI titled “Improve mobile UX” might yield three smaller PBIs titled “Improve mobile dashboard UX,” “Improve mobile ticketing UX,” and “Improve mobile reporting UX.” You could also use the Area or Tag field to help keep these items associated.

What should be done with the original epic PBI? You have three options:

• ■   Remove or delete it.

• ■   Rename it to become one of the new, smaller PBIs.

• ■   Promote it to a Feature work item, making it a parent of the new, smaller PBIs.

I want to focus on the last option. When I say “promote,” I mean to change the work item type from PBI to Feature, as I’m doing in Figure 5-5, essentially moving it up one level so that I can make it a parent of the new, split PBIs. The Developers would never directly forecast or develop the Feature work item; it would just be used for organization and planning. When all the child PBIs were done, the Feature work item’s state could be manually set to Done. The advantage to this approach is that it establishes a visual hierarchy and additional context. You can learn more about changing a work item type here: https://aka.ms/change-work-item-type.

FIGURE 5-5 You can change a PBI work item to a Feature work item.

After changing the PBI work item to a Feature work item, you’ll need to refresh the backlog, show the Mapping pane, and drag the child PBIs to the new feature. These actions will create a parent-child relationship. This hierarchy can be visualized in several ways, as I discussed in Chapter 3. Personally, I like to just include the Parent column so that I can see the parent’s title and click it if need be. You can see this at the bottom of Figure 5-6.

FIGURE 5-6 You can display the parent feature of newly split and linked PBIs.

Tip You should avoid creating same-category links. These are parent-child links among work items of the same type, such as PBI to PBI. In Azure Boards, when a backlog contains same-category nested work items like this, the system cannot properly reorder work items. The system disables the drag-and-drop reorder feature and not all items will display under these circumstances. You may also run into error messages.

Instead of nesting PBIs within the Stories backlog, Microsoft recommends that you maintain a flat list. In other words, only create parent-child links one level deep between items that belong to a different category. Use the Feature work item type when you want to group PBIs, and use the Epic work item type when you want to group features.

You can also use the bulk-modify feature to link several PBIs to a feature at once. Just select the related PBIs, right-click the selection, and select Change Parent (Figure 5-7). Here you can select the parent feature (or parent epic if you’re working in the Features backlog).

FIGURE 5-7 Azure Boards allows you to set the parent of many PBIs at once.

Establishing a feature-to-PBI hierarchy keeps the Product Backlog flat. There are no placeholder rows in there to distract you. This allows items to be reordered completely independent of one another. In other words, you are not forced to keep all the related work together. For example, maybe the Product Owner wants to improve the mobile dashboard UX and mobile ticketing UX now, but improving the mobile reporting UX can wait a few Sprints.

So, which option for handling epic PBIs is best? You can probably guess my answer. Let the Product Owner decide. Some Product Owners don’t like to create hierarchies and don’t like to use portfolio backlogs. Others do. Different Product Owners adopt naming conventions, or use areas or tags to group items together.

If you have different stakeholders who want to see different views and levels of the Product Backlog, then establishing a hierarchy can be beneficial for their sake. Doing so helps everyone visualize and understand the breakdown of work and be able to visualize the plan and assess progress at various levels. It also helps the Scrum Team explain to stakeholders the physics of complex product development and its trade-offs (such as “We had to do it this way because we couldn’t physically build the whole feature in one Sprint”).

Fabrikam Fiber Case Study

Paula has decided that when epic PBIs arrive in the Product Backlog, they will be split into smaller PBIs and have a Feature work item established as their parent. She recommends that each team member add the Parent column to their backlog to visualize this hierarchy.

Importing Product Backlog Items

Prior to your team using Azure Boards to maintain its Product Backlog, it’s likely that your organization will maintain one or more lists of work. One list might track high-level requirements, another might contain feature requests from the users, and yet another will track bugs. These lists can range from an exotic arrangement of sticky notes, to an Excel spreadsheet, to a Microsoft SharePoint list, even to a dedicated ticketing tool.

Merging all this data into a common Product Backlog can be difficult, and I’m not just talking about navigating the people, politics, and permissions. Meaningful data must be extracted, transformed, and loaded. Information gaps must be filled. Duplicates must be resolved. Fortunately, Azure Boards offers a few options for importing and bulk-modifying work items.

Although you can continue to use Excel for bulk import and updates, doing so is no longer required. The native way of importing work items is to import directly from a CSV file. This CSV file must contain the Work Item Type and the Title fields, at a minimum. You can include other columns as needed. You can see an example of a CSV import file in Figure 5-8. All work items you import are created in a New state. This rule means that you can’t specify field values that don’t meet the field rules for the New state.

FIGURE 5-8 Here is a sample CSV import file of Product Backlog items.

The Import Work Items feature is found on the Work Items page as well as the Queries page. Simply choose the CSV file and import it. The process loads the imported work items into a query-style view. Imported items are in an unsaved state, allowing you to verify and tweak the results before saving them. Any import issues are highlighted so that you can resolve them. You can fix an issue by opening the work item directly or by using bulk-edit to fix several work items with the same issue.

Azure Boards also allows you to export work items to CSV. You’ll need an existing query—one that contains all the columns you are interested in. Simply run the query and export to CSV. The exported file format looks similar to the import file format. If the exported file contains (at least) the ID, Work Item Type, Title, and State fields, you can reimport it later—after making changes—to update the work items in Azure Boards.

Smell It’s a smell to continue importing items into the Product Backlog after it’s been created. Once Sprints begin and regular feedback yields a flow of new PBIs, they should be added to the Product Backlog, not some other list. The Product Owner and stakeholders should avoid storing those items and then dumping a batch of them into the backlog. It could be that the product definition has been broadened or a new scope of work has arrived. It could also be that the Scrum Team has dependencies on other teams or individuals in the organization that is batching work as well. As with all dependencies, these should be identified and mitigated.

Using Microsoft Excel

As everyone knows, Excel is extremely easy to use, and everyone in the organization seems to have a copy. I’ve used it to create dozens of Product Backlogs over the years. What many people don’t know is that it can be used as an extract, transform, and load (ETL) tool as well. Okay, maybe it’s not advertised as such, but it’s true.

Using Excel, you can extract the data from an existing list by using copy/paste, one of the Get Data functions, or some form of automation. The data can then be transformed (normalized) and finally loaded (published) to Azure DevOps. Excel really is the Swiss Army knife of data manipulation.

There are a number of ways to import existing backlog items using Excel. Here is a high-level, step-by-step approach that I recommend:

1. Download and install the (free) Azure DevOps Office Integration.

2. Launch Excel.

3. Open a blank worksheet.

4. Rename the Sheet1 worksheet to Source.

5. Add a second worksheet named Target.

6. Load your data using the clipboard or one of the Get Data functions into the Source worksheet.

7. Select the Target sheet.

8. On the Team ribbon, click New List, connect to the Azure DevOps project (if necessary), and click Input list.

9. On the Team ribbon, click Choose Columns.

10. Select the Product Backlog Item work item type, add any additional columns you might need, and remove any extraneous columns. As you can see in Figure 5-9, Area Path, Description, Business Value, Effort, and Tags are good columns to consider adding.

11. From the Source sheet, copy the relevant columns and paste them into the respective columns in the Target sheet. You may need to set some fields manually (such as Work Item Type and Product Owner). You can also use the bulk-edit capabilities in Azure Boards to set these fields after import.

12. Clean up the data, especially if you are importing Area Path, State, or any numeric data.

13. On the Team ribbon, click Publish. If an error occurs, correct it and then publish again.

FIGURE 5-9 Select work item columns when importing PBIs from Excel.

The normal state transition workflow of a PBI work item is New ⇒ Approved ⇒ Committed ⇒ Done. For our custom, Professional Scrum process, I changed it to New ⇒ Ready ⇒ Forecasted ⇒ Done. When importing historical items, you must initially import the work item in the New state, but then you can switch to any of the other states after that. For example, even though the normal workflow is New ⇒ Ready ⇒ Forecasted ⇒ Done, you can import items as New and then change them directly to Done. This approach avoids the tedium of having to “walk the states,” or publishing back to Azure Boards each time.

After you’ve published the work items, you can continue to use the Excel spreadsheet to make bulk edits to that set of data. If this sounds like something you might want to do, then you should save the workbook, giving it a meaningful name. If this was a one-time import and you are happy with the results, you can discard the workbook. You can always create a work item query and open it in Excel if the need arises.

As a corollary, Microsoft makes it easy to create a query to return the items in the Product Backlog. From any of the backlogs, you can click the Create Query option and create a personal or shared query that will return the items in the backlog, including the exact columns that are currently being displayed. This query can then be opened in Excel for review, charting, or bulk-editing. Just remember not to futz with the Backlog Priority field, because the sparsifier will override those values at your most inconvenient opportunity.

Tip You should install and use the Open in Excel Azure DevOps extension. It makes it easy to open multiple work items or an entire query in Excel. By using the extension, you can skip having to use the Team ribbon, connecting to Azure DevOps, selecting your project, and so forth. It will do it all for you in one click, right from Azure Boards.

Bulk-modifying Work Items

Excel is not your only choice for making bulk edits. Azure Boards provides a native bulk-modify experience as well, which you can use to quickly make the same change to a number of work items. With this feature, you can edit fields, add or remove tags, reassign work, or move work to a specific Sprint. You can also use bulk-modify to change the work item type or move work items to other projects.

From the Backlogs page or a query result, you can use the same multiselect approach that you use when selecting multiple items (such as files) in Windows. To select multiple work items, press and hold the Shift key and select the first and last work item at the ends of the range you want to select. Or, you can select multiple work items by holding down the Ctrl key as you click each work item until all are selected. You can also use a combination of the Shift and Ctrl key approaches.

With the work items selected, you can right-click the selection (or click the context menu of any of the rows) and select one of the bulk-edit options. You can directly assign the selected work items to a new team member, add a link to them, move them to a different Sprint, move them out of a Sprint (back to the backlog), or other operations. You can also click Edit, which allows you to bulk-modify any field or fields in those work items.

Editing a work item is different than opening it. When you open a work item, you can view and change all the fields for that one work item. When you edit, you can specify a value for one or more fields that will be applied to all of the selected work items, as I’m doing in Figure 5-10. You can also set a note for the history, which I recommend for increased transparency and traceability.

FIGURE 5-10 Azure Boards allows you to bulk-modify work items.

If you plan on importing items regularly and/or have a lot of complex data scrubbing to perform, you might consider building a custom solution. Azure DevOps has many wonderful, well-documented APIs. These APIs are based on REST, OAuth, JSON, and service hooks—all standard web technologies broadly supported in the industry.

Your custom solution could read the source data, perform any transformations that are required, and then use the Azure DevOps APIs to connect to the project and create or modify the work items. You can code against the APIs directly, or you can use one of these client libraries: .NET, Go, Node.js, Python, Swagger, or Web Extensions. For more information on extending Azure DevOps, visit https://docs.microsoft.com/en-us/azure/devops/integrate.

Tip Fellow Professional Scrum Trainer Martin Hinshelwood created and manages the Azure DevOps Migration Tools project on GitHub. These tools allow you to migrate work items and other artifacts from one project to another, even between organizations. These tools do a lot more than just bulk editing, and there is some great functionality and sample code to reference. Visit https://github.com/nkdAgility/azure-devops-migration-tools to learn more.

Removing a Product Backlog Item

From time to time, you may want to remove a work item from the Product Backlog—or anywhere else in Azure Boards for that matter. The work item may have been created in error, may have been created in the wrong project, may have been a duplicate, or otherwise needs to go. You have a couple of choices when removing a work item. Which approach you take depends on how your organization feels about auditing work item changes and deletions.

Your first choice is to straight up delete the work item. Deleted work items won’t appear in backlogs, boards, or queries. Deleted work items are moved to a Recycle bin on the Work Items page, from which you can recover them if needed. You can’t open work items that have been moved to the Recycle bin. Work items in the Recycle bin can also be permanently deleted. Once permanently deleted, the work item is gone, with no record that it ever existed.

You can delete a work item from within the work item form or by right-clicking it in the Backlogs page; from query results; from the Boards page; or even from the Taskboard. You can also bulk-delete work items, using the previously mentioned bulk-edit approach.

Note Azure Test Plans artifacts such as test plans, test suites, test cases, and so on are also types of work items. The method for deleting them, however, differs from deleting non-test work items. I will describe how to delete these test-related work items in Chapter 7, “Planning with Tests.”

The other choice for removing a PBI work item is to simply change its state to Removed. By changing the state of a work item to Removed, you effectively remove it from all backlog and board views. The work item still exists, but Azure Boards knows not to display them except for in work item query results. To force removed items to not show up in query results, you must add a clause that filters on the State field. Removing work items—as opposed to deleting them—is generally preferred by organizations with strict audit requirements.

Tip When changing a PBI work item’s state to Removed, you should also add a comment to the Discussion section explaining why the item was removed. Adding a comment will help increased transparency and traceability.

Effective Product Backlog Creation

Writing a book about the fusion of Scrum, tools, and practices is difficult. I have to constantly balance any guidance I offer with that of the team’s mandate to self-manage. I could just write “let the team decide” on every page of this book, but that would get very old. Most of my recommendations are for teams new to Scrum and Azure DevOps. I fully understand that these teams will develop their own behaviors over time, which is great. I only desire that these behaviors are healthy ones. To that end, Table 5-2 lists some of the proven practices that I recommend when creating a Product Backlog.

TABLE 5-2 Proven practices when creating a Product Backlog.

Tip	Reason
Keep titles short and to the point.	Sometimes the user will have only the title to go by and screen real estate is at a premium in Azure Boards.
Consider tagging bug PBIs with “Bug.”	Using a query or a filter to identify which PBIs are bugs can be helpful.
Leave items in the root iteration.	Don’t set the iteration path of a PBI until the Sprint in which they are forecast for development. It sets expectations that may not be met because things change. For release planning, consider using the Forecasting tool or a story mapping extension.
Don’t create and link tasks or test cases.	You should wait until the Sprint in which the PBI is forecast for development to link tasks or test cases. Things change, and your planning effort could be wasted, or worse— an incorrect/outdated plan could be executed.
The Assigned To user should be the Product Owner or left blank.	Since the Product Owner is responsible for the Product Backlog, it makes sense that they are the person assigned.
Use the right tool for the job.	Use the Backlogs page for adding, ordering, bulk-modifying, refining, and forecasting. Use Excel for importing or (offline) bulk-editing.
Link to documents rather than attach them.	External documents can be linked to a work item, as well as discovered and manipulated independently. Attached documents are harder to find but may be more useful when archiving development efforts.

Reporting a Bug

In Scrum, no differentiation exists between a feature and a bug. Both represent something that must be developed in the software product. Both provide a value. Both have a cost. By default, Azure DevOps does differentiate. As I mentioned in Chapter 3, in Azure Boards the Bug work item type tracks additional information over a PBI work item, such as the steps to reproduce, severity, system information, and the build number that the bug was found and fixed in. Bug work items also don’t have a Business Value field—although there can definitely be value in fixing a bug. Other than these differences, a Bug work item is treated just like a PBI work item in Azure DevOps. Insofar as Scrum is concerned, bugs are refined, sized, forecasted, and decomposed into a plan, and then developed according to a Definition of Done—just like any other PBI.

Fabrikam Fiber Case Study

Since the Scrum Team is using the custom Professional Scrum process, the Bug work item type has been disabled. Even if it hadn’t, Paula had decided not to use the Bug work item type. This is because this work item type does not have a Business Value field and it also contains several extraneous fields. This is not to say that the Product Backlog won’t contain bugs, but rather that the Fabrikam Scrum Team will use the PBI work item type to track them. They will tag the PBIs accordingly and put the repro steps and system information into the Description field.

Each Scrum Team may handle the discovery and classification of bugs in their own way. Before reporting a bug, someone should ensure that it is a valid bug. It could be that the odd behavior that someone experienced was by design, was a training issue, or was something that had already been reported or even fixed. This identifying and sorting process is known as bug triage or bug repro.

Triage also includes identifying the severity, frequency, risk, and other related factors. Triaging bugs can sometimes be a collaboration of the Scrum Team and stakeholders such as subject matter experts and business analysts. Their input can help elaborate on domain-specific issues and risks.

Smell Regardless of whether a team is using the Bug work item type or not, it’s a smell when I don’t see bugs in a Product Backlog. One concern is that the team isn’t testing the product. It could also be that the stakeholders aren’t reporting bugs. From a planning perspective, I’m more worried that bugs are being reported and tracked in another system. There may be another team (such as QA) or a sub-team that is handling testing and tracking with a separate tool.

Also, large organizations tend to have centralized trouble-ticket or issue-tracking systems. Software bugs found in production typically begin their life in these systems. They shouldn’t end up there, though. Those bugs should be triaged and, if valid, added to the Product Backlog. Without having bugs in the Product Backlog alongside feature requests, the Product Owner won’t be able to order the items effectively to maximize the work of the team and the value of the product. I would also caution against tracking bugs in both systems, which can be confusing and wasteful.

As with any PBI, anyone should be able to report a bug. Bugs, just like everything else in the Product Backlog, are validated, estimated (sized), ordered, and eventually forecast to be fixed. It’s the Product Owner’s prerogative to approve the bug fix, leave it in its current state (New), move it along on its journey to being ready, or remove it from the Product Backlog.

Fabrikam Fiber Case Study

Paula, exhibiting the Scrum Values of respect and openness, has invited any stakeholder, including users, to report an issue or bug directly. Currently these are emailed to Paula; she will triage them and, if valid, create a PBI with a “Bug” tag. Eventually she’d like the team to build feedback capability directly in the product—not just for sad things like issues, but for happy things like feature requests as well.

What Makes a Good Bug Report?

A bug report is just that—the reporting of a bug or other unwanted behavior in the software product. In order to write a good bug report, and thus create a good PBI, you must include enough information for the Scrum Team to understand it, gauge its impact on the business, and decide if it’s worth fixing.

A good, clear title is a must. A team member should be able to grasp the essence of the bug from the title alone. If the Product Backlog contains many work items, having a clear title will help the Developers as they work the bug through refinement, forecasting, and development. It also saves a stakeholder from having to read the whole work item to grasp its context.

Tip When I’m coaching a Scrum Team, I encourage them to brainstorm and then capture their definition of a bug—which is a lot harder than it sounds. It’s important to have a definition and to have everyone—including stakeholders—understand it and abide by the definition before using the term in open conversation. With a transparent, generally understood definition of a bug, the usage of that potentially caustic moniker should drop, along with any unconscious perception of a low-quality product.

You should report only one bug per PBI. If you document more than one bug, some may be overlooked. Atomic bug tracking helps in the same way atomic testing does—it provides a precise understanding of what’s working and what isn’t.

Also, a picture is worth a thousand words. Sometimes words just can’t demonstrate the issue that an annotated screenshot can. Team members will appreciate these extra efforts because they need to find the problem in the shortest amount of time. Any helpful documentation can also be linked or attached to the work item.

It is also a good idea to specify system information, including the build number that produced the failure. This build number can either be the one generated by Azure Pipelines or an assembly or product version number. Having a precise build number or version number will provide more information and help the team identify the exact problematic build or release. Otherwise, if the team uses a more current build or release version, they might search for a problem that was already fixed or otherwise mitigated. If they reference an older build or release, the problem code may not have been integrated yet. All of this information can be tracked in the Description field of the PBI work item.

Bug work items should always contain the observed as well as the expected results. This practice is useful because sometimes Developers don’t think that a bug is really a bug, or they might claim that “it works on my machine”—not knowing what “works” actually means. The opposite can also be true, which is the expected result is working on their machines and the production deployment is different. Regardless, the variance between expected and observed should help prove the case. Also, generic descriptions like “This is a bug” or “It should work” are not helpful because the bug in question may not be immediately obvious to the others.

Note You should describe the observed results (the steps to reproduce the bug). This can be added to the Description field of the PBI work item. Also, you should consider using the Acceptance Criteria field to track the expected results (how it should work), as shown in Figure 5-11. Knowing the expected results can help the team create better tests. If you have additional acceptance criteria to list, you can do that in addition to the expected results. Be careful, though. You should avoid adding new “features” to a bug fix, unless the Product Owner is on board. If you have other unrelated improvements to make, consider creating a separate PBI work item to refine and plan. Gold plating (adding unrequested and thus wasteful features) should be avoided, even when fixing bugs.

FIGURE 5-11 It’s helpful to specify both the observed and expected results when reporting a bug.

When reporting a bug, be professional. Don’t write titles like “Help!”; “It’s broken”; “Got an error”; “What happened?”; or “Dude!” These kinds of titles are devoid of content at best and irritating at worst. Titles should be short and concise. Save the explanation (and commentary) for the Description and Acceptance Criteria fields. Your fellow team members can’t read minds, so don’t include notes like “Do you get what I mean?” Try your best to explain yourself. Don’t assume the team members will just follow things that are written on the bug report. Also, don’t play politics. Using a bug report to score political points is detrimental to the health of the team and the product. It also violates the Scrum Value of respect.

You’ve probably experienced firsthand that if you don’t document the exact steps to reproduce an issue, you’ll forget them very quickly. Be as specific as necessary, without being wasteful. Proofread the fields before saving. A proofread bug report has a much higher chance of being understood by others and of being fixed. Table 5-3 lists many proven practices when reporting bugs.

TABLE 5-3 Proven practices when reporting bugs.

Practice	Reason
Triage the bug.	To determine if it is a valid bug and not a feature, training issue, or by design
Keep titles concise but descriptive.	To save the user from having to read the entire PBI work item to get the context
Report only one bug per work item.	To estimate (size), order, and forecast each bug independently
Consider tagging bug PBIs with Bug.	To query or filter on which PBIs are bugs vs. feature requests/enhancements
Include screenshots with annotations.	To report a bug in an effective way
List repeatable steps to reproduce the bug.	To provide as much context to the team as possible in order to help them identify and fix the source of the failure; use the Description field
Provide expected results as well as observed results.	To show what success looks like as the team fixes the bug; use the Acceptance Criteria field
Include system information, the build number, and/or the version number.	To provide as much context to the team as possible in order to help them identify and fix the source of the failure; use the Description field
Use proper grammar, spelling, and tone.	To be professional

Where Do Bugs Come From?

Bugs can be introduced in a software product any number of ways. There is little point in attempting to name, blame, or shame any particular person, because there are so many sources that can cause a bug. Scrum Teams collectively own everything, including bugs. Besides, blaming and shaming have no place in Professional Scrum, because they violate the Scrum Value of respect.

Determining why something failed can sometimes take two or three times the amount of effort over just fixing it. Make sure the time spent analyzing the root cause adds value to your product or your process. The Sprint Retrospective is a good place to discuss any findings and potential corrections for the future. Whatever the finding, remember that the team collectively owns the quality (good or bad) of the product.

Here are a few reasons that bugs occur in software products:

• ■   Feature creep

• ■   Inadequate process

• ■   Inadequate tooling

• ■   Inexperienced developers

• ■   Poor coding

• ■   Poor test coverage

• ■   Poorly understood requirements

Real bugs, as in the tiny crawly creatures, also have a well-defined lifecycle, according to their species. Their metamorphosis is a good metaphor for software bugs. It often starts with a simple observation of a probable source of customer dissatisfaction (the egg); proceeds to a well-defined report of the observed symptoms, steps to reproduce, and a technical investigation (the larva); proceeds to a fix for the problem (the chrysalis); moves to a working and tested build (the adult); and finally proceeds to a deployed fix (the death of the bug). Like real bugs, not all software bugs survive to adulthood. Of course, unlike real bugs, software bugs can retreat back to their larval state when the fix is unsuccessful. Those are called reactivations, which I will cover in a bit.

Tip I often meet Developers who feel the need to trace a newly discovered bug back to the original PBI. Although this linking can be done easily in Azure Boards, I always ask, “Why?” If they want to see what the original acceptance criteria were, that’s valid. They should consider copying and pasting the applicable criteria into the new PBI, making any tweaks. If, instead, they are looking for a reason why it broke, that can be better answered by looking at the code or tests. If they want to find out the size (such as story points) of the original PBI so that they can deduct it from their velocity, that’s a dysfunction, not to mention a waste of time. Time spent dwelling on past mistakes is time that can’t be used to work on the Sprint Backlog and achieve the Sprint Goal. Discuss your findings during the Sprint Retrospective. Remember, software development is complex. It is very hard and full of risk. We’re not always going to get it right. Focus on improving in the next Sprint.

In-Sprint vs. Out-of-Sprint Bugs

Not all bugs are equal—so they shouldn’t be treated equally. Bugs found in code running in production, or in a done Increment waiting to be released to production, are out of the scope of the Developers’ forecast work for the Sprint. As such, those bugs should be handled the same as any feature request. The bug should be added to the Product Backlog, considered by the Product Owner, refined by the Scrum Team, and forecast in a future Sprint.

If the Product Owner deems the bug as critical and requiring an immediate fix, then the team should drop what they are doing and fix it. This interruption may or may not require their full capacity. Regardless, everyone must realize that the Sprint’s forecast may be missed and that achieving the Sprint Goal may be in jeopardy. The Product Owner weighs these risks and, after collaborating with the team and stakeholders, makes the decision.

Note Unplanned work is just that. You can’t plan it at the start of the Sprint. If the team’s plan (such as tasks) consumes 100 percent of their available time, they will have no capacity left to handle unplanned work like an emergency bug fix. When the emergency does happen, it may cause the team to miss their forecast and therefore cause a drop in their velocity—if they are tracking velocity. Since velocity (or some similar measure) is an input to Sprint Planning, a decrease will provide slack time in the next Sprint for handling emergencies and other unplanned work. High-performance Scrum Teams watch their capacity while maximizing the value that their work produces.

I refer to bugs found in the code that the team is working on during the Sprint as in-Sprint bugs. These may not be bugs according to the team’s official definition; rather, the code is just not quite there yet. Most teams’ Definition of Done includes some form of “Code compiles,” “There are no errors,” or “All tests pass.” In these cases, it’s not really a bug—the team just isn’t done yet.

Smell It’s a smell when bugs are created as a result of a failed test, such as an acceptance test. I often see this when there is another team, such as QA, that is doing the acceptance testing—which is not Scrum—and their preferred method of communication is not talking face to face but reporting a bug as a work item. Failed tests are not bugs. Failed tests simply indicate that the team is not done yet. At most, the team should update their plan (for example, add another task to the Sprint Backlog) to fix the code and pass the test.

An example of an in-Sprint bug would be when the team is developing new functionality, such as adding a new ticketing summary report, but gets blocked because of how they coded a controller in a previous Sprint. Fortunately, the controller issue doesn’t affect any in-production functionality, but it does block them from completing the PBI in their current Sprint. Had they determined that the controller issue impacted functionality currently in production, then the Product Owner would’ve wanted them to fix it immediately. In this case, they have to fix it anyway in order to complete the new report.

The goal for in-Sprint bugs is to fix them, not manage them. Ideally, you want to fix all bugs discovered during a Sprint. If you don’t, they could affect the Developers’ ability to achieve their forecast or Sprint Goal. Here is the guidance I give to new Scrum Teams for handling in-Sprint bugs:

• ■   If it’s a small bug (< n hours to fix) and won’t affect the Developers’ ability to achieve the forecast or Sprint Goal, then just consider it part of the plan and fix it. The Developers decide what n equals and can adjust it during Sprint Retrospectives. A value of 2 feels right to me for smaller teams getting started.

• ■   If it’s a larger bug (> n hours to fix) and won’t affect the Developers’ ability to achieve the forecast or Sprint Goal, then create a PBI work item, add it to the forecast, associate a Task work item (if they are using tasks), and have a Developer address it during the Sprint. The PBI will help raise transparency and explain the reason behind any hiccup in progress.

• ■   If it’s a larger bug (> n hours to fix) and will affect the Developers’ ability to achieve the forecast or Sprint Goal, then create a PBI work item and discuss it with the Product Owner. They may value the bug fix over another PBI in the forecast. If not, then the bug will be left in the code this Sprint and the bug PBI will be refined by the Scrum Team and forecast in a future Sprint.

But what about creating a bug PBI as a simple reminder? Suppose a team member finds a small bug and it’s not possible to immediately collaborate on a fix. Rather than creating an additional PBI, I recommend simply updating the plan (such as creating another task associated with the PBI that the bug blocked). If the team is not using tasks, then adding another PBI to the Sprint forecast—to represent the bug—could be an option as well. Let the team decide. Regardless, an issue like this should be brought up with the other Developers at the earliest opportunity, even if collaborating to fix it isn’t immediately possible. The Developers must decide if it can be fixed in the current Sprint or in a future one. If the bug is left in the code, the Product Owner should be consulted. Everyone will need to realize that the Sprint’s forecast may be missed and that achieving the Sprint Goal might also be in jeopardy. What’s worse, you have now added technical debt to your codebase and product.

Conversely, I refer to bugs found in production code, or in a done Increment waiting to be released to production, as out-of-Sprint bugs. Typically, these bugs don’t affect the code associated with the forecast work that the team is currently working on. If code is affected, then treat them as in-Sprint bugs. Otherwise, consider the guidance I offer to Scrum Teams for handling out-of-Sprint bugs:

• ■   If the Product Owner determines that the bug is critical, the team should do whatever needs to be done to create and release a fix. Everyone must realize that the Sprint’s forecast may be missed and that achieving the Sprint Goal might not be possible as well.

• ■   If the bug is not critical, then create a PBI work item. The Product Owner will decide if the bug should be refined and when it should be considered for Sprint Planning.

• ■   If the number of critical bug occurrences is high and/or increases, consider adjusting the team’s capacity or dedicating people to supporting issues like these. The Scrum Team should also look for the root cause of these critical bugs and experiment with solutions. Oftentimes, if quality is low, the Scrum Team should slow down and focus on getting done (according to their definition) and thus improving quality.

An example of an out-of-Sprint bug would be when the team is developing new functionality such as adding a new ticketing summary report and, while reviewing the controller code, sees that it’s not working correctly. The team is not blocked from completing the PBI in their current Sprint, but they know that the bug has been deployed to production. Even though no users have reported it yet, they should inform the Product Owner, who may want them to immediately fix it. In that case, they may miss their forecast and possibly even their Sprint Goal.

Note If you suspect a bug exists, write a failing test to verify your suspicion. The test could be automated (such as a unit test) or manual (such as a Test Case work item). I know that I’ve said that unplanned items in the Product Backlog should not have any associated tasks or test cases. My reason for this guidance is to reduce waste, such as defining the how (through tasks and test cases) too early. An exception to this guidance would be a situation where a Test Case work item existed before the bug PBI work item. If this happens, don’t discard the test case. It may still be of value in a future Sprint when the team works on the fix.

Bug Reactivations

Reactivations occur whenever a bug (previously thought Done) appears again. This could be caused by changes in the environment such as infrastructure upgrades, new deployments, or even having the closed the bug prematurely. People sometimes mark bugs as Done when the underlying problem has not been fixed. When this happens, it introduces waste into the process. A team member has to write and run a test and reopen the bug PBI. The original code may need to be refactored or scrapped and then retested. At a minimum, the reactivation doubles the number of context switches and usually more than doubles the total effort required to complete the corresponding work. Frequent reactivations are a smell of a deeper dysfunction.

Watching the rate at which reactivations occur is important. A tiny amount of waste might be acceptable, but a medium-to-high (or rising) rate of reactivations should be a smell, warning the team to diagnose the root cause and fix it. Although sloppy development practices are an obvious possibility, other potential causes include poor bug reporting, inadequate test management, and overly aggressive triage. The Sprint Retrospective is a great venue for such discussion.

Fabrikam Fiber Case Study

Paula has created an “Active Bugs” shared query, which returns all PBI work items with the tag Bug in the New, Ready, or Forecasted states—everything except for Removed and Done items. She also added a Query widget to the team’s dashboard that shows a real-time count of Active Bugs. She configured the widget with conditional formatting so that when there are more than a specified number of bugs, it will change the background color of the widget to attract attention. You can see an example of this in Figure 5-12. Clicking the widget will open the query and show the active bug PBIs.

FIGURE 5-12 Query dashboard widgets show work item counts at a glance.

Refining the Product Backlog

Product Backlog refinement is an ongoing, part-time activity where the entire Scrum Team meets to better understand the upcoming items in the Product Backlog. When the time is right, the team will size the items to know if they are ready for Sprint Planning. If, when, and where the Scrum Team meets to refine the backlog is up to them. The Scrum Guide only recommends doing it and suggests that it take no more than 10 percent of the team’s capacity during the Sprint. It is not an official event and is completely optional.

Tip Although Product Backlog refinement is an optional activity, it is a critical one. It provides a regular opportunity to evolve the Product Backlog. I recommend that Scrum Teams establish a regular cadence of refinements. They can inspect and adapt the frequency as needed. Fellow Professional Scrum Trainer Simon Reindl suggests refining a PBI three times before considering it ready for forecasting and development.

Initially, a PBI work item need only have a title to be added to the Product Backlog. The values for the other fields will begin to emerge and continue until the time that it is forecast for development. It may still change after that. Prior to forecasting the PBI, the Scrum Team should have a solid understanding of the request, its value to the customer, what Done looks like, and a feel for its size—the level of effort required to develop it. This evolution can occur at Sprint Planning, at Sprint Review, or during a Product Backlog refinement session.

Tip Scrum Teams generally refine their Product Backlog from top to bottom, making sure that there is understanding and consensus around the highest-ordered items first. There are times, however, when the team may want to jump to a specific PBI that isn’t near the top. To find a work item in a large Product Backlog, I recommend using the Azure DevOps search feature at the top. Searching will take you to the work items page and display the search results just as though you ran a query. As you can see in Figure 5-13, I am searching for the keyword links and have found the work item I’m interested in.

FIGURE 5-13 You can search your Azure DevOps project for artifacts in many ways.

As details emerge and consensus forms, you should edit the work item and make any updates. Updating can occur at any time during the Sprint, but especially during Product Backlog refinement. Here are some PBI changes that might be made as a result of refining the Product Backlog:

• ■   Add or improve description   A description that explains the who, what, and why is added.

• ■   Assign business value   The Product Owner assigns a business value.

Tip Business value is an abstract number. It doesn’t necessarily relate to any direct value measure (sales, revenue, new customers, products sold, etc.). That said, just as a PBI’s size/effort can be helpful when comparing relatively to other PBIs, so can business value. For Product Owners learning to track business value, I coach them to base their number on a Fibonacci sequence, similar to how many teams base story points. The difference is that I multiply the story points by 100 to make them look more “value-y.” The business value sequence I recommend to teams is 100, 200, 300, 500, 800, 1300, and 2100.

• ■   Link documents   The team links to or attaches any supporting documents.

• ■   Add acceptance criteria   After collaborating with the stakeholders (customers, users, and/or subject matter experts), you add acceptance criteria.

• ■   Size   After reaching a baseline understanding of what Done looks like, the team sizes the PBI relative to other items—already done or sized—in the Product Backlog.

• ■   Split   The Scrum Team decides that the PBI is too large to be completed in one Sprint.

• ■   Set state to Ready   The Scrum Team decides that this PBI is ready for Sprint Planning.

• ■   Set state to Removed   The Product Owner determines that the PBI is a duplicate or otherwise unnecessary.

I want to take a few pages to discuss a few of the specific actions taken while refining the Product Backlog: specifying acceptance criteria, sizing a PBI, and splitting a PBI. Although these are not new topics, and there are many good books out there, I want to discuss the Professional Scrum approach to these practices.

Specifying Acceptance Criteria

Professional Scrum Developers don’t forecast any work until they know what Done looks like. For example, there’s not a lot of detail to go on if a PBI is simply titled “Monthly ticket report.” Even if it has an awesome description that reads, “As a technician, I want to see a monthly report of my support tickets so that I can better prepare for the future,” a team would be able to build any of a hundred different reports that are fit for that vague purpose. Rather than commune this information on the fly, or build the wrong thing (and hope to be corrected by feedback), the team needs to take a more measured approach to knowing what to develop and what Done looks like.

Being more deliberate can be performed by collaborating with stakeholders and identifying acceptance criteria. This task can be performed by anyone on the Scrum Team, but often it is the responsibility of the Product Owner. A high-performance Scrum organization is one where the stakeholders themselves (such as the users) are able to craft their own PBIs, including acceptance criteria.

Using acceptance criteria is a lightweight, agile way of establishing requirements and defining success for a PBI. Think of it as the work item’s specific Definition of Done. Acceptance criteria should define the what but not the how. The team should have free rein over how to build it, so long as it meets the acceptance criteria and the Definition of Done. Figure 5-14 shows a PBI with an emerging set of acceptance criteria.

FIGURE 5-14 Each PBI should have adequate acceptance criteria.

Each individual acceptance criterion should be testable. In other words, you should be able to create and execute a manual or automated test to verify that each bullet is done. Sometimes it will take multiple tests to verify one criterion; other times one test can verify multiple criteria. I will dive deeper into this in Chapter 7.

Scope Creep

One of the agile values is “Responding to change over following a plan.” So, what happens when the Product Owner needs to change the acceptance criteria? If the PBI work item hasn’t been forecasted yet, there’s no problem. Someone should update the criteria and the Developers would need to resize the item at the next refinement opportunity.

If the Developers have already forecast (and possibly started) the work for the current Sprint, the reflex is to resist the change. After all, don’t the rules of Scrum “unionize” the team to protect against practices like scope creep? Some might think so, and they would be wrong. The Product Owner is responsible for maximizing the value of the product, as well as the work of the team. Sometimes these two responsibilities conflict, especially when business or market drivers demand an immediate change. This is not to say that there won’t be waste.

The correct response is for the entire Scrum Team to collaborate on bringing value to the product with respect to this change. This is the N (negotiable) in the INVEST acronym I talked about in Chapter 1, “Professional Scrum.” Yes, the forecast may slip. Yes, the Sprint Goal may not be achieved. Yes, there will probably be waste. But, in the opinion of the Product Owner, the immediate change to the product is worth these costs to ultimately avoid much greater risk and waste. The Sprint Retrospective should be used to better understand what happened and how to keep it from happening again in the future.

Fabrikam Fiber Case Study

Because Sprints are only two weeks long, scope creep is not much of a problem. When it does happen, the team is professional and collaborates with Paula to maximize the value of the product. Just as Paula has learned to trust the Developers’ abilities, so have they learned to trust her judgment.

Sizing Product Backlog Items

Higher-ordered items in the Product Backlog are clearer and more detailed than lower-ordered ones. More accurate sizing is possible due to this increased clarity and detail. The lower in the order (the further down the backlog), the less detail exists. This is why a team should size the items toward the top of the Product Backlog rather than in the middle or at the bottom. It would be a waste of the team’s time to size items that are too far down the backlog, especially ones that the Product Owner doesn’t want in the first place. I discussed this, and the concept of the Product Backlog iceberg, in Chapter 1.

Each item in the Product Backlog is unique. It’s difficult to size something unique that is being built for the first time, especially if it is unlike anything built before. Traditional estimation techniques do not work. As odd as it sounds, if you want to be more accurate, you should be less precise. It’s okay to be precise on small things, like Sprint tasks (“create a web form,” “update a stored procedure,” “create a load test,” etc.). Each of those tasks could be estimated in hours with some accuracy. For larger items, such as PBIs, you want to use a scale that is less precise, like T-shirt sizes (S, M, L, XL) or a Fibonacci sequence of numbers (1, 2, 3, 5, 8, 13, 21, etc.).

In Scrum, the team is responsible for all estimates. It follows that the people who will perform the work (analysts, designers, testers, coders, writers, etc.) make the final estimate. In smaller teams, where the Product Owner and/or Scrum Master is also a team member, they will have input on the estimations as well. Never underestimate how long good estimation takes, but also realize that too much analysis and estimation can have a diminished return on the time invested.

Tip Scrum offers three formal opportunities to refine the Product Backlog: during Sprint Planning, during Product Backlog refinement, and during Sprint Review. It’s best to do the bulk of your estimation during Product Backlog refinement. This way, the Developers can spend less time sizing and forecasting work at the next Sprint Planning.

Sizing should be performed as late as possible. Early estimates are less accurate than ones made later. You always know more today than you did yesterday. You also don’t want to waste the team’s time estimating items that are way down the list. Proper ordering of the Product Backlog can reduce waste when estimating. The Product Owner should know what’s coming up next or soon thereafter, and focus on those items. The Product Owner should wait until obviously large (epic) PBIs are split.

Sometimes it’s a chicken-and-egg problem, though. The Product Owner needs an idea of the cost (size/effort) of a PBI before they can order it. A solution for adding value to the estimation process is for the team (or a proxy) to provide the Product Owner a rough order of magnitude estimate, such as a T-shirt size (S, M, L, XL). This approach can give the Product Owner enough insight to be able to order the item effectively, or even decide that they don’t want it at all. A more thorough estimate, provided by the entire team and using a more precise technique, can be performed at a future refinement session.

The Scrum Guide does not prescribe any particular size technique or unit of measure. Teams can use whatever practice and values they wish. Planning Poker is a very popular method. Story points are popular too—although some teams prefer to call them “complexity points” or something very abstract like “acorns.” I once coached a team building pharmaceutical software that went so far as to use the term “Vicodins.” (Vicodin is a prescription pain medication, which is fitting given some of their painful user stories.) Whatever term you decide on, using an abstract measure like a story point is preferred for sizing complex work. Abstract values have an advantage over temporal values (hours, days, ideal-days, weeks) because their usage doesn’t imply a commitment or a plan or anything that smells like a schedule. For example, if you were estimating in days, a stakeholder might conjure up a specific expectation—and then write it on the calendar!

Note An agile estimation technique is not a silver bullet. In fact, it’s the worst form of estimation except for all the others that have been tried. Agile estimation techniques won’t remove uncertainty from early estimates, but they also won’t waste unnecessary time. Estimates will become more accurate over time. This is due to the empirical nature of agile estimation techniques, where actual work is taken into account. The most important outcome of any agile estimation practice is the conversation and shared understanding—not the number. After shared understanding is established—as manifested by a consensus of the PBI’s size—refinement of that PBI can be considered complete.

By default, the PBI work item has an Effort field to hold the estimate. In the customized Professional Scrum process, I kept this field and simply changed its label to Size. This numeric field indicates the relative rating for the amount of work (or complexity) that the PBI implementation will require. Larger numbers indicate more effort/complexity than smaller numbers.

Tip I’m often asked if size is the same as effort. My answer is yes, as long as the unit of measure is abstract, is not a measure of time, and is used relative to other PBIs. I’m also asked if size is the same as complexity. My answer again is yes, as long as the unit of measure is abstract, is not a computer science measure of complexity (such as function points), and is used relative to other PBIs. In other words, if the unit of measure is abstract, size can mean effort or complexity. Since it’s confusing, Professional Scrum Teams simply use the generic term size. Regardless of what you call it, the Effort field in the PBI work item will hold the value.

Planning Poker™

Planning Poker is a tool for estimating complex work, such as software development. It is a technique where each team member selects an estimate card such that it cannot be seen by the other players. After everyone has selected a card, all cards are exposed at once. The Product Owner and Scrum Master don’t participate in the estimation game unless they are also a team member. If necessary, the Scrum Master facilitates the process. The Product Owner should offer support where needed, such as answering questions. Other stakeholders or domain experts may attend the refinement session to offer support but not to participate in estimation.

The units represented are typically story points in a limited Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, etc.). The cards are numbered in this sequence to account for the fact that the larger an estimate is, the more uncertainty or risk it contains. The 0 card, though rarely used in my experience, is a way of letting the others know that the PBI is invalid or has already been implemented in some form. Some decks may also contain larger numbers, question marks, infinity symbols, or coffee break cards. Remember, it’s about the conversation, learning, and shared understanding—not the number on the cards.

Here’s how I facilitate a Planning Poker session:

• ■   Select a baseline PBI   The Developers select and reference a medium-sized PBI that they have worked on recently. This PBI will be arbitrarily assigned a size of 5 and will be used as a baseline. The referenced item doesn’t have to be similar to the one being estimated, but it helps. Over time, as the team collaborates and learns more about the domain and its technology, it can select a new baseline PBI and then resize items in the Product Backlog.

• ■   Read the PBI   Typically, the most knowledgeable Developer or domain expert for the given PBI provides a short overview. This could also be the Product Owner.

• ■   Discuss the PBI   The Developers are given a timeboxed opportunity to ask questions and to discuss and clarify assumptions and risks. A summary of the discussion can be recorded.

• ■   Size the PBI   The Developers consider the size of this PBI as compared to the baseline PBI, selecting an initial size (1, 3, 5, 8, 13, or 21). Everyone reveals all cards at the same time—to avoid some Developers influencing (anchoring) other team members’ opinions. If, for example, a team member initially thinks a PBI’s size is 3 (as compared with the baseline PBI), they should also consider the perceived uncertainty, technical debt, risk of using new technology, lack of tests, and so forth and consider increasing the size, possibly to 5.

Note Anchoring occurs when a team member discusses or hints at their estimate prior to the revealing of their card. A cross-functional team normally has a mix of conservative and impulsive estimators. Some Developers may have an agenda too, like wanting to maximize the time they can have to work on an item. Conversely, the Product Owner—who is in the room during refinement—is likely to want something done as quickly as possible. Compromise through collaboration becomes important at this juncture.

The estimate becomes anchored when the Product Owner, or one of the more experienced Developers, says something like, “This should be easy” or “I could do that in a day.” Anchoring can also go the other way, when someone says something foreboding like, “Isn’t that the component riddled with technical debt?” or “Wait, that code doesn’t have any unit tests.” Whoever starts the conversation with the statement, “That’ll take the entire Sprint!” immediately has an impact on the thinking of the other Developers. Their estimates have now been anchored by that statement, even subconsciously. They are now likely to make at least a subliminal reference to that opinion. For example, those who were thinking 5 points are likely to increase their size estimate.

Anchoring becomes a particular problem if an influential team member makes the original statement that described the PBI. Because the remainder of the team has been anchored, they may consciously or otherwise fail to express their original unity. In fact, they may fail to even discover that they were thinking the same thing. This can be dangerous, resulting in sizes that are influenced by agendas, attitudes, alphas, or opinions that are not focused on developing done, working product.

• ■   Discuss the outliers   The team member(s) with the highest and lowest estimates are given an opportunity to explain why they picked such an outlying number. If no outliers exist, and the team is generally in consensus on a size, then you can record it and move on to the next PBI.

• ■   Repeat until consensus   The team should repeat the estimate process until a consensus is reached. The size is then recorded in the PBI work item. If consensus is not reached after a few rounds, estimation should be tabled until the next refinement session since a compromise can’t be attained at this time. More will be known later. For situations where consensus is far off, I coach the outliers to do “homework” to verify/prove that the work is so hard or so easy. This homework will be “due” at the next refinement session.

Although several online estimation and sizing tools, including some that integrate with Azure DevOps, are available, I prefer in-person, physical cards that support high-fidelity conversations and learnings. For distributed teams or remote Developers, tools may be necessary.

Wall Estimation

A Scrum Team can employ many practices to estimate the size of a PBI. Though Planning Poker is the most popular, several of my fellow Professional Scrum Trainers use an affinity estimation practice called wall estimation, also known as white elephant sizing. It is loosely based on the idea and workflow of a white elephant gift exchange. If you’ve never heard of it, feel free to look it up. Here’s how I facilitate a wall estimation session:

• ■   Create a board   Start with the team standing in a half circle, facing a whiteboard with seven columns—each representing a Fibonacci number (1, 2, 3, 5, 8, 13, and 21). On a nearby table is a timer and a stack of PBIs to be sized.

• ■   Select a baseline PBI   The Developers select and reference a medium-size PBI that they have worked on recently. This PBI will be assigned a size of 5 and be placed above the 5 column. It will be referenced as the baseline. Over time, as the team collaborates and learns more about the domain and technology, it can select a new baseline PBI and then resize items in the Product Backlog.

• ■   Prepare the PBIs   The PBI cards can be index cards or sticky notes. The cards contain the titles and short descriptions of the items that you are about to estimate.

• ■   Size a PBI   The first team member will start the timer, pick the card off the top of the deck, read it out loud, stick it in one of the columns, provide a reason for their decision, and then stop the timer. I leave the timer duration up to the team. Some teams practice a faster, “silent” version, where they skip the explanation.

• ■   Change the size   The next team member can choose to size a new PBI just like above, or change (steal) the size of a previously sized PBI—just like the classic white elephant exchange. If changing a size, the person needs to move the PBI to a new column and provide a reason for the change.

• ■   Repeat until done   The next team member repeats the above, sizing a new PBI or changing the size of a PBI already on the board. This continues until all of the PBIs are sized or the timebox expires. The sizes are then recorded in the PBI work items. Once all new PBIs have been sized—and only disagreements with existing sizes remain—Developers can start skipping their turn. Skipping a turn suggests that team member agrees with the estimated sizes on the board.

Everyone should have laser focus and listen actively to the estimator. Everyone else should remain silent. There should be no discussion, judgment, or sighing. If a team member does not size the PBI within the time limit, the PBI card is returned to the bottom of the pile. If consensus is not reached and a compromise can’t be made for a specific PBI, estimation should be tabled until the next refinement session when more is known. For situations where consensus is far off, I coach the outliers to do homework to verify/prove that the work is so hard or so easy. This homework will be due at the next refinement session.

Fabrikam Fiber Case Study

The team has decided to use Planning Poker to estimate the size of the PBIs in the Product Backlog. This occurs primarily at the Product Backlog refinement sessions on Friday mornings. Since they have been working together for some time on the same domain, using familiar tools and technologies, the team’s baseline is well established and understood. Estimation sessions go smoothly and consensus is usually achieved quickly.

Splitting Product Backlog Items

Earlier in this chapter, I discussed splitting epic PBIs into two or more PBIs. Now that I am talking about refining the Product Backlog, let’s review this guidance. When a PBI is too large for the team to complete in one Sprint, it must be split. For some teams, even that is too risky and their working agreement states that a PBI cannot be larger than what can be done in a few days’ work.

Regardless of what the team defines as “too large,” there will be times that a PBI needs to be split. For example, if a team tracks velocity and computes that the next Sprint’s velocity will be between 16 and 20, then any PBI that is larger than 13 points should be split. If the team wants to further reduce risk, it may have a working agreement for one-half of that so that any PBI larger than 8 points should be split.

There are several recommended ways to split a PBI, and they all have one thing in common—they split the PBI vertically. That is to say, there will be a vertical slice of functionality containing a small piece of each architectural/component layer in the solution. For example, if our application has a model, view, and controller (MVC) architecture, each PBI’s implementation would include a piece of work in each MVC component, as well as the persistence store (such as a database) and the user interface (UI). This way, each PBI could be inspected, because it has a UI and is functional all the way down to persistence. You can see an example of how I might split a large PBI by acceptance criteria in Figure 5-15.

FIGURE 5-15 When splitting a PBI, consider splitting by acceptance criteria.

When splitting a PBI, the team should resist the urge to split it horizontally—which would be by architectural or component layers (data, service, controller, UI, etc.). This may seem a logical way to go, but it will result in undone work at the end of a Sprint. Even though the PBI will build and pass tests, there is nothing that is potentially releasable or even inspectable at the Sprint Review. Stakeholders don’t want to inspect mock-ups, wireframes, code, or passing tests. In Scrum, especially Professional Scrum, every PBI should offer an independent slice of value when released and that value should be able to be inspected during Sprint Review.

Definition of Ready

When a PBI work item is initially created, it is in the New state. Once the item is ready for Sprint Planning, its state should be changed to Ready. When the Developers forecast to deliver the item in the current Sprint, its state should be changed to Forecasted. Finally, when the PBI work item is done according to the Definition of Done, the state should be changed to Done. Unfortunately, there can be many states in-between New and Ready that Azure Boards does not support by default.

More and more teams are adopting a definition of ready as a way to avoid starting work on PBIs that are ill-defined, such as those that do not have clearly defined acceptance criteria. Although some teams can do this implicitly, others desire a formal definition to explicitly communicate this working agreement with their Product Owner and stakeholders. Some teams even want to make this definition actionable and visual, such as using a board to move a PBI through its workflow on its journey to ready.

During Product Backlog refinement, detail, order, and estimates are added or improved until each PBI is ready. In effect, Product Backlog refinement helps “de-risk” Sprint Planning as well as development. By observing a definition of ready, a Scrum Team reduces the risk of the team being caught flat-footed in Sprint Planning and during development. With this agreement, the Developers won’t begin working on items (or even consider forecasting them) that are not sufficiently well described and understood.

Smell It’s a smell when I see a definition of ready used as a gate that prevents a team from considering more valuable, late-breaking items, in favor of better understood, ready items. I have no objection against Developers deciding that a PBI is too large to forecast, but using the definition of ready as leverage against the Product Owner is a dysfunction. Remember, agility comes from the ability to “change on a dime, for a dime” and a definition of ready used in a dysfunctional way prevents that. If the Product Owner wants to bring brand-new PBIs into Sprint Planning—even if they are not ready—they should be allowed to.

The “definition of ready” is not an official Scrum artifact or practice. It’s not even mentioned, per se, in the Scrum Guide. In other words, it doesn’t have “teeth” like the Definition of Done does. This is not to say that it’s not useful. It can be very useful, if not abused. Scrum is a great framework for experimenting with practices, such as the definition of ready.

The creation and use of a definition of ready should be a team decision—to include the Product Owner. It can be codified into a working agreement. This working agreement will apply to Product Backlog refinement, or any other time the Scrum Team works on making a PBI ready for Sprint Planning.

A definition of ready is often loosely based on the INVEST mnemonic covered in Chapter 1. The INVEST mnemonic was created by Bill Wake in 2003 as a reminder to the agile community of the characteristics of a good quality user story. Here is a review of INVEST:

• ■   I (Independent)   A PBI should be self-contained. It should be possible to bring it into a Sprint without a dependency on another PBI or an external resource.

• ■   N (Negotiable)   A PBI should leave room for discussion about its optimal implementation.

• ■   V (Valuable)   A PBI should deliver a measure of value to the stakeholders.

• ■   E (Estimable)   A PBI must have a size, ideally relative to other PBIs.

• ■   S (Small)   A PBI should be small enough to be forecasted and developed in a Sprint.

• ■   T (Testable)   A PBI should have clear, testable acceptance criteria that define Done for this item.

I recommend teams not use INVEST directly as their definition of ready but rewrite it to make it more emergent and Scrum-friendly. Also, additional steps can be added that are specific to their organization, team, and culture. These steps can also help visualize the PBI’s evolution to ready. Here is a sample definition of ready workflow loosely based on INVEST:

• ■   New   The PBI was just added to the Product Backlog. Maybe only a title exists.

• ■   Interested   The PBI is of interest to the Product Owner.

• ■   Description   The PBI contains a short, meaningful description. The user-story description format (“As a…,” “I want…,” “So that…”) can work well.

• ■   Value   The PBI has been assigned a measure of value—possibly relative to other PBIs.

• ■   Acceptance Criteria   The PBI’s acceptance criteria are identified, describing what done looks like for this PBI.

• ■   Dependencies   The PBI’s dependencies (technical, domain, people) are identified.

• ■   Sized/Estimated   The PBI’s size—relative to other PBIs—is determined.

• ■   Ready   If the PBI is understood and small enough, then it is ready for Sprint Planning and development.

Implementing a Definition of Ready

For Scrum Teams wanting to create a visual—and actionable—definition of ready, I recommend using the Kanban board. Rather than further modify the already customized Professional Scrum process and add extra workflow states, it’s much easier to customize the columns on the Kanban board. Using the Kanban board, a Scrum Team can enact their definition of ready by adding new columns in-between the New and Ready states defined in the PBI work item type.

By default, the Board’s columns match the workflow states of the PBI work item type. In our case, using the Professional Scrum process, those columns are New, Ready, Forecasted, and Done. I will add additional columns in-between New and Ready to represent my definition of ready. To do this, I open Team Settings on the Boards page, go to Board Columns, and add the new columns, taking care to map the new columns to the New workflow state. I also set all the Work in Progress (WIP) limits to 0, since the Scrum Team won’t actually be practicing Kanban as they refine their Product Backlog. Before leaving Team Settings, I also added the Business Value field to the cards. You can see the final result, split into two screenshots to represent the left and right sides of the board respectively, in Figure 5-16.

FIGURE 5-16 The Kanban board (left and right sides) can be used to model a team’s definition of ready.

Notice in Figure 5-16 that the PBI cards contain more and more information as they progress through the columns from left to right. For example, cards don’t enter the Value column unless they have a Business Value. Cards don’t enter the Sized column unless they have an Effort (size). Cards that are too large (for example, 21 points) don’t make it into the Ready column.

If I had added more fields to the cards (which can make for a messy board), you’d see Description and Acceptance Criteria also emerging in their respective columns. What you wouldn’t see is the State changing. Cards remain in the New state all the way up through Sized. On this journey, only their board column changes. Once a card moves into the Ready column, the underlying workflow State changes to Ready. If you return to the Stories backlog and add Board Column, then you can see this State versus Board Column relationship, as shown in Figure 5-17.

FIGURE 5-17 From the Stories backlog, you can see which board column a PBI is in.

Tip Even though I have disabled the Bug work item type in my custom Professional Scrum process, some pages in Azure Boards might still have UI elements pertaining to bugs. For an improved experience, you should select the Bugs are not managed on backlogs and boards option in the Working with bugs section of Team Settings, as I’ve done in Figure 5-18.

FIGURE 5-18 Configure Azure Boards to not manage bugs on the backlogs and boards.

Ordering the Product Backlog

The Product Backlog should be ordered by the Product Owner to maximize the value of the product being developed. This order can be influenced in many ways: ROI, value, risk, effort, business priority, dependency, technical debt, learning value, votes, or necessity. The Product Owner has the final say in the ordering of the items.

Items at a higher order (toward the top of the Product Backlog) are clearer and more detailed than lower-ordered ones (toward the bottom of the Product Backlog). The items toward the top are also closer to being ready for Sprint Planning and development. The higher the order, the more a PBI has been considered, and the more consensus exists around its size.

Smell It’s a smell when I see Developers ordering the Product Backlog. This is the responsibility of the Product Owner. It could be that the Developers are doing so at the Product Owner’s request. It could also be that the pertinent items need to be arranged to minimize technical dependencies. This is fine, as long as the Product Owner is okay with the order. The worry is that the Scrum Team has an absent Product Owner who defers both the “what” and “when” decisions to the Developers.

In Azure Boards, you can order the Product Backlog by dragging items up or down. If you click and hold on an item, you can drag it above or below another item and then drop it. You can see this in Figure 5-19, as the Monthly sales report PBI is dragged to the top of the Product Backlog. When it is dropped, it will be the highest-ordered item in the Product Backlog. Reordering like this assumes you have at least a Basic access license. Stakeholder access doesn’t support dragging and dropping in the Product Backlog.

FIGURE 5-19 A Product Owner can order the Product Backlog by dragging and dropping PBI work items.

As your Product Backlog grows, you could potentially find yourself looking at hundreds of items. Although each backlog can display up to 10,000 work items in Azure Boards, if you get more than a few hundred, dragging, scrolling, and dropping can become a nightmare. That is why a professional, engaged Product Owner should be constantly paying attention to the Product Backlog, keeping it in good shape and ordering it. The more important and well-known items should be at the top, with “ready” items at the very top.

Ordering a large Product Backlog can be very tedious—you may have to drag up or down several “screens” of items. If this is your situation, your Product Owner my find it faster to right-click and select Move to position. Having to use this feature often, however, can be a smell of having an out-of-control Product Backlog.

Tip It’s fine to remove or delete old, stale PBIs from a Product Backlog. These might be the PBIs that always sink to the bottom, never getting implemented. This decision should lie with the Product Owner and may be influenced by the organization’s policies and guidance. If a deleted feature is really valuable, it will pop up again at some point in time.

Planning a Release

Every organization will do some level of release planning. A Professional Scrum Product Owner is able to forecast and plan releases at any time—with varying degrees of confidence. Release planning depends on the Product Backlog being refined and correctly ordered. It also requires the Developers to know what they are historically capable of delivering each Sprint. This is typically quantified in either a velocity or Throughput metric. You will learn more about flow metrics, such as Throughput, in Chapter 9.

In Scrum, the Product Owner is responsible for managing the expectations of the stakeholders. This is done through Product Backlog management (refinement and ordering) and then forecasting when an item or items will be released—or which items will be released by a specific date. The release plan is often a separate visualization, such as a query result or report, but it can also be inferred by observing the Product Backlog.

A Product Owner, Developer, or stakeholder can use the Forecasting tool to help visualize their release plan in real time, directly on the refined Product Backlog. By specifying a value for the Developers’ velocity, the Forecasting tool will show which items in the backlog can be completed within future Sprints, as you can see in Figure 5-20. As the Product Backlog is refined and reordered and velocity changes/stabilizes, the Forecasting tool can be run again.

FIGURE 5-20 A team can use the Forecasting tool to see which PBIs might be completed in upcoming Sprints.

A risk of generating a separate release plan, outside the context of the Product Backlog, is that stakeholders may infer an expectation of scope, schedule, or cost. Any release plan is just a forecast, and the stakeholders need to be made aware of that. As with all types of work in the complex space, especially the invisible IT work of software development, things can change, especially plans.

Note Release planning is not officially part of Scrum, although it is a popular complementary practice. Keeping the Product Backlog healthy (refined and ordered) is the best input for release planning, regardless of the type or scope of release planning.

A release plan establishes the goal of the release and includes the highest-ordered PBIs, the major risks, and the overall features and functionality that the release will contain. It also establishes a probable delivery date and/or feature set, and a cost that should hold if nothing changes. The organization can then inspect progress and make changes to this release plan on a Sprint-by-Sprint basis.

The release plan will probably start with a large margin of error unless the Developers have a decent amount of empirical evidence of executing, sizing PBIs, failing, learning, and succeeding as a team. Over time, this mounting empirical data will become apparent as a stable velocity or Throughput. The release plan will become increasingly refined (and accurate) as development progresses and empirical data is gathered. Again, the key to release planning is to have the Product Backlog in good shape, which is the result of an engaged Product Owner and constant refining by the whole Scrum Team.

In traditionally managed organizations, their planning process is done at the beginning of the effort and largely left unchanged as time passes. In an organization practicing Professional Scrum—where inspection, adaptation, and transparency are sacrosanct—the Product Owner defines the overall goal with stakeholders and works with the Developers to define probable outcomes. This style of planning requires substantially less time than to build a traditional release plan.

Traditional release planning efforts are up-front “guesstimates” that seldom prove true. Scrum’s just-in-time planning is ongoing during all of its events. Because of that, agile release planning practices consume more effort than traditional release planning practices. Empirical methods usually do take longer than guessing. Scrum’s approach, however, adds more value and probability of success because dynamic planning is more valuable than a static plan.

Release planning in Scrum supports three types of release models:

• ■   By date   A date-target planning model is one where the Increment must be released by a specific date. The scope (features and bug fixes) that will be in that release must be negotiable. Having a refined Product Backlog will help the Scrum Team and stakeholders identify that scope.

• ■   By feature   A feature-target planning model is one where the Increment is released once it contains a minimum set of features and bug fixes (to be determined by the Product Owner). The release date must be negotiable. Having a refined Product Backlog will help the Scrum Team and stakeholders identify that date.

• ■   Continuously   A Continuous Delivery (“on-demand delivery”) release model is one where the Increment can be released to production as each PBI (feature or bug fix) is done. Release can occur at any time during the Sprint, assuming the Definition of Done is met. This model is popular for server/cloud-hosted software. Having a refined Product Backlog will help the Scrum Team and stakeholders know what will be released next.

Release planning occurs all the way through a product’s lifecycle, not just at the beginning. Release planning typically corresponds to the version increment of the software product. As the Developers progress through the Sprints, their empirical data (such as velocity) can be applied to the Product Backlog to assess how the release plan compares to reality. If a release burndown chart is being maintained, it will include data from past Sprints and can provide a view of the progress. This information is an important input to release planning.

Fabrikam Fiber Case Study

Originally, the Fabrikam Fiber website was released to production quarterly. After the adoption of Scrum and Azure DevOps, this improved to monthly, and then to every two weeks. The plan is to move to Continuous Delivery (CD) once more automated testing is achieved.

Story Mapping

It is a fact of life that developing the desired functionality in a complex product will require more than the available time and budget. Based on its assessment of progress, a Scrum Team can make changes to its release plan without compromising quality. The most effective variation to make is to the scope. This involves deferring some PBIs until later, thus reducing the scope for the current release.

That said, when stakeholders become dismayed when their desirements are removed from a Sprint, it’s not productive to sit back and quote the Scrum Guide to them or even hand them a copy of this book—although I wouldn’t mind if you did. Yes, there are rules in place to minimize scope creep from occurring during the Sprint and the release. Unfortunately, the Scrum Values, as well as the Agile Manifesto’s values, outweigh them. In other words, it is important that PBIs—even up to and including those in the Sprint—be “negotiable” so that their desired outcome can be achieved by pragmatically adjusting the sophistication of the product’s implementation. In other words, it’s more important to deliver business value in the form of working software than to follow a plan. I do believe I’ve read that somewhere.

Enter story maps. Where a Product Backlog is one-dimensional, easily showing the ordering of the items, story maps are two-dimensional. Working from a large flat list like a Product Backlog can be difficult to navigate and stakeholders can become lost, not knowing what should come next. Story maps can be arranged in many ways to visualize a release plan and even the Product Goal or vision. The goal of a story map is to keep the focus on the users and their experience, resulting in a better conversation and shared understanding.

Story mapping is the process of creating a story map. Story mapping begins by taking a selection of PBIs (typically user stories) and organizing them on a board. This organization will represent the order in which new functionality is delivered and can be used to plan future Sprints. By visually arranging the PBIs on a story map, your team is breaking the user’s journey down into understandable parts. Having the stakeholders involved will ensure that desires are represented correctly and nothing gets missed. It also helps them understand the realities and trade-offs of release planning. If a stakeholder wants a medium-sized PBI added to the release, then they will first have to pull a medium-sized PBI out of the release. Story maps make this very obvious.

Story mapping consists of ordering PBIs along two dimensions. The horizontal axis is for arranging user activities and functionality in an order that describes the behavior of the product, possibly as a user’s journey. The vertical axis is for planning the increasing sophistication of the product over time. Figure 5-21 shows a sketch of a story map and these two axes.

FIGURE 5-21 Story maps keep the focus on the users and their experience, resulting in a better conversation and shared understanding.

Image provided by SpecFlow

Even with only two axes, story maps can be created in many different configurations. PBIs can be grouped in many ways on the horizontal axis (by feature, by epic, by journey, by persona, etc.). PBIs can also be grouped in many ways on the vertical axis (by Sprint, release, or date).

Tip Because the story map involves the entire product, the entire Scrum Team and stakeholders should be involved in its creation and evolution. Perhaps these updates are done during Product Backlog refinement. Perhaps it’s done at Sprint Planning, or even Sprint Review. Let the team decide when and where. Having a physical story map posted in a public area where it is visible to the stakeholders can be a powerful information radiator.

Traditionally, story maps are created using sticky notes that are placed on walls or whiteboards. These physical maps are not without their disadvantages. Walls are not transportable, and unfortunately, that means those story maps are only temporary. It is also difficult for remote stakeholders to view these boards in real time. Also, let’s not forget the cleaning person at night who can wreak havoc on physical boards and maps. I’ll explore an electronic tool alternative in the next section.

SpecMap

SpecMap is an Azure DevOps extension by Tricentis that provides story mapping capability for Azure Boards. SpecMap enables a Scrum Team to build story maps from work items, providing a visualization and basis for discussing the needs of your stakeholders. These conversations can assist a Product Owner in ordering the Product Backlog to deliver the biggest impact.

SpecMap imitates traditional story maps that use sticky notes. A team can depict the user journey as a series of activities, place PBIs on the map, and easily create slices. These artifacts are represented by work items and even Sprints. Assigning a PBI to a particular activity automatically creates a parent-child link between the two. This means that creating a story map in SpecMap can assist a team in Product Backlog refinement and even Sprint Planning.

The key features of SpecMap include the following:

• ■   Map user activities to PBIs via drag and drop   Dragging PBI work items from the Product Backlog to a story map can create a mapping to a Feature or Epic work item.

• ■   Structure the Product Backlog   New work items are automatically added to the Azure Boards backlog hierarchy with the corresponding feature as the work items’ parents.

• ■   Plan releases with slices   Slice a story map to represent Sprints and releases. PBI work items don’t have to be assigned to future Sprints.

• ■   Add tasks to PBIs and keep track of your progress   Use SpecMap during a Sprint, adding tasks directly to a PBI card. An overview of the completion status of those child tasks is displayed, allowing a team to keep track of its progress.

After you install the SpecMap extension, it will become available in the Boards hub. First, you will need to add a new map to the project and give it a name. Next, you’ll map out the user’s journey (or sets of features) from left to right as a series of high-level activities that your product has an impact on. These activities can optionally be linked to a work item, such as a Feature or an Epic. You can also track the outcome expected when this activity has been completed.

Next, you can assign related PBIs to these activities by dragging and dropping from the appropriate backlog on the left. You can drag and drop these PBIs up and down to change their priority, and you can drag the PBIs horizontally to position them under a different user journey or activity. A Product Owner can do this before a Sprint Review or other stakeholder meeting, or during any Product Backlog refinement workshop.

Next, you can slice groups of PBIs horizontally to plan Sprints or releases. You can drag PBIs up and down to put them into these different slices. These slices may be linked to iteration paths (Sprints) to automatically assign the PBIs when they are added or dragged to that slice. You can see a SpecMap story map being constructed in Figure 5-22.

FIGURE 5-22 SpecMap is an Azure DevOps extension that lets you easily create story maps.

Tip Professional Scrum Teams don’t preassign, or pre-bucket, PBIs to future Sprints. In addition, undone PBIs that aren’t in the current Sprint should have their iteration set to the root, indicating that they are in the Product Backlog. For this reason, it is not recommended to link SpecMap slices to iteration paths, because you’d be pre-bucketing work into these future Sprints. The good news is that you don’t have to do this. SpecMap maintains its slice state in the map, and not in the work items.

Unlike SpecMap, Microsoft’s Delivery Plans requires work items to have their iteration set in order to arrange them in the release. This pre-bucketing of work is wasteful because things can change. New PBIs may be introduced or existing plans may change, requiring someone to go back and change items that were set in future iterations. What’s riskier is that stakeholders, or others who don’t understand that this is just a forecast, might infer scope, schedule, or cost by observing the work items directly (and seeing that they have been assigned to a future Sprint).

Product Backlog Checklist

Each Scrum Team and Product Owner will create and manage their Product Backlog differently. Those just getting started with Scrum and/or Azure DevOps may have more work to do to get their Product Backlog imported and refined. Other teams and Product Owners may have a fairly light flow of new PBIs, resulting in a Product Backlog that stays in good shape. In either case, it’s safe to bet that your Product Backlogs will go through seasons of churn. For example, right after a large release there may be lots of feedback that needs to be captured in the Product Backlog.

Regardless of where you and your team are, this checklist can be helpful in preparing your Product Backlog and keeping it healthy and refined.

Scrum

• ❒   Talk to stakeholders to see if there is interest in having an Epic or Features backlog.

• ❒   Identify existing lists in your organization that would constitute a Product Backlog.

• ❒   Decide which items would go on the Epics, Features, or Stories backlog.

Azure DevOps

• ❒   Import the PBI, Feature, and Epic work items from existing lists.

• ❒   Ensure that PBIs all have short, meaningful titles.

• ❒   Tag those PBIs appropriately (Bug, High Risk, etc.).

• ❒   Assign PBIs to the Product Owner (or leave them blank).

• ❒   Set the PBI States appropriately (New or Ready).

• ❒   Ensure all PBIs are set to the appropriate area.

• ❒   Ensure all PBIs—not in the current Sprint—are set to the root iteration.

• ❒   Ensure all PBIs have a short, meaningful description.

• ❒   Ensure all PBIs have adequate acceptance criteria.

• ❒   Ensure all PBIs have been assigned a value.

• ❒   Ensure all PBIs have been sized.

• ❒   Promote large PBIs to Features.

• ❒   Promote large Features to Epics.

• ❒   Map PBI work items to Features and Features to Epics accordingly.

• ❒   Order the Product Backlog with “ready” PBIs at the top.

• ❒   Consider ordering by ROI (value/size) in lieu of another approach.

• ❒   Avoid linking PBI work items to other PBI work items.

• ❒   Avoid assigning PBIs to future Sprints.

• ❒   Avoid creating associated tasks prior to Sprint Planning.

• ❒   Avoid creating associated test cases prior to Sprint Planning.

Chapter Retrospective

Here are the key concepts I covered in this chapter:

• ■   The Backlogs page   This page is used to create and manage the Product Backlog in a flat, one-dimensional format.

• ■   Importing work items   You can natively import work items from CSV files in Azure Boards.

• ■   Microsoft Excel   Excel is used to query and bulk-update multiple fields with different values.

• ■   Bulk-modifying   Azure Boards offers the ability to make bulk edits to work items. This can be done from query results or the Backlogs page.

• ■   Epic   An Epic is any PBI that is too large to be developed in a single Sprint. Epics must be split. Not to be confused with the Epics backlog.

• ■   Features backlog   This is a hierarchical backlog of work items that sits above the Stories Backlog in Azure Boards. A Feature work item can be the parent of a PBI work item.

• ■   Epics backlog   This is a hierarchical backlog of work items that sits above the Features backlog in Azure Boards. An Epic work item can be the parent of a Feature work item.

• ■   Removing vs. Deleting   When you set a work item’s state to Removed, it will disappear from the various backlogs and boards but can be discovered by running a query. Deleted work items are sent to the Recycle bin, where they can be recovered or permanently deleted.

• ■   Reporting a bug   Bugs found during a Sprint should just be fixed; otherwise, create a PBI work item to report the bug. These PBIs can be optionally tagged as “Bug.” Annotated screenshots and listing expected results are good ideas. Failed tests are not bugs.

• ■   Refinement   This is an optional activity in which the Scrum Team works to understand and estimate upcoming items in the Product Backlog in order to get them ready for Sprint Planning.

• ■   Sizing   Use empiricism and low-precision practices, such as T-shirt sizing, to size PBIs and develop a shared understanding of its complexity. There are many agile estimation techniques available, such as Planning Poker.

• ■   Definition of ready   This is an optional practice a Scrum Team can use to visualize the workflow for getting a PBI ready for Sprint Planning. The Boards page can be used to help track PBIs on their journey to becoming ready.

• ■   Ordering the Product Backlog   Use drag-and-drop in the Backlogs page to order the Product Backlog. There are many ways to order the Product Backlog—by ROI, risk, dependency, learning, or by the whim of the Product Owner.

• ■   Velocity   Use the built-in analytics to see (in real time) the Developers’ velocity in order to use it for forecasting.

• ■   Forecasting   Use the Forecasting tool and the Developers’ velocity to view which PBIs might potentially be developed in the upcoming Sprints.

• ■   Release planning   Use a refined Product Backlog to forecast what will be released by a specific date or when a specific set of functionality might be released. Professional Scrum Teams value planning over having plans.

• ■   Story maps   A story map is a two-dimensional visual representation of the Product Backlog that can be used to develop a shared understanding with stakeholders. SpecMap is an Azure DevOps extension that supports the creation of story maps.