Chapter 6

The Sprint

The heart of Scrum is the Sprint—a timebox of one month or less during which a done, usable, and releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints consist of Sprint Planning, Daily Scrums, the development work, Product Backlog refinement, the Sprint Review, and the Sprint Retrospective.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long, the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost. The frequency of feedback, experience and technical excellence of the Developers, and the organization and Product Owner’s need for agility are key factors in determining the length of a Sprint.

The first event within a Sprint is Sprint Planning. The entire Scrum Team attends and participates in Sprint Planning. Stakeholders may attend—if their presence adds value to the conversation by helping clarify details about the PBIs in question. The first part of this chapter will cover Sprint Planning—its inputs and outputs, and how Azure DevOps supports Sprint Planning to capture the Sprint Goal and the Sprint Backlog.

Each day of the Sprint, the Developers meet for the Daily Scrum. This is a timeboxed meeting, lasting no longer than 15 minutes. The Developers use this opportunity to synchronize with one another and to develop a plan for the next 24 hours. The Developers should update their remaining work, at least daily, so that they can inspect the progress of their forecasted work. Beyond that, what the Developers do during the course of the day depends on what is required to get the forecasted work done and achieve the Sprint Goal. Professional Scrum Developers make sure that the work performed is always of value to the organization. The second part of this chapter will be spent on those daily activities that the Developers perform as they pertain to Azure Boards.

In summary, this chapter focuses on how to use the various tools in Azure DevOps, especially Azure Boards, to plan and manage the work in the Sprint Backlog. If you are more interested in the concept of the Sprint and the Sprint Backlog, and less on how to manage them using Azure Boards, I refer you back to 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.

Sprint Planning

At the beginning of the Sprint, the Scrum Team attends Sprint Planning, where the work to be performed in the Sprint is planned. This meeting is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. For teams practicing a two-week Sprint, I suggest a timebox of four hours or less. Initially, the Scrum Team may take the entire timebox, but after a few Sprints, they should start getting the hang of it and take less time. Also, by regularly refining the Product Backlog, time spent in Sprint Planning should decrease.

Sprint Planning can be conceptually broken down into three topics: the what, the how, and the why. In the first topic, the Developers work to forecast what functionality (PBIs) will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the PBIs that, if completed, would achieve this goal. The Sprint Goal provides direction as the Developers create the forecast. The entire Scrum Team collaborates on understanding the work of the Sprint.

In the second topic, the Developers decide how they will build this functionality into a done product Increment during the Sprint. This is called the plan, and it can be represented in many ways. The forecasted PBIs selected for this Sprint, along with the plan for delivering them and the Sprint Goal, make up the Sprint Backlog.

Tip It is not expected that the Developers will completely generate the Sprint Backlog during Sprint Planning. Some work may be stubbed out for later discovery. It’s important for work to be planned for at least the first few days of the Sprint. Also, Professional Scrum Developers don’t fill their capacity to 100 percent during Sprint Planning—they leave slack time for other activities.

What happens during Sprint Planning in these topics is completely up to the Scrum Team. In early Sprints, they may spend 75 percent of their time forecasting and 25 percent of their time creating a partial plan. Later, as they have more experience practicing Scrum, they may balance out the topics. After regularly refining the Product Backlog for a period of time, Sprint Planning may look more like 25 percent forecasting and 75 percent creating the plan, with a much shorter meeting.

Sprint Planning has the following inputs:

• ■   Product Backlog   The refined Product Backlog that, hopefully, contains at least a few ready PBIs toward the top.

• ■   Objective   What the Sprint should achieve. Provided by the Product Owner. This may end up being the Sprint Goal, or at least contribute to the Sprint Goal.

• ■   Increment   Knowledge of the Increment’s content and health. If the product is software, then this would include the quality of the code base, technical debt, lack of tests, etc.

• ■   Definition of Done   A shared understanding of what it means for work to be complete in order to ensure transparency. Generally speaking, if the Definition of Done is stringent, then less work would be forecasted than with a simpler Definition of Done.

• ■   Past performance   The Developers’ performance in recent Sprints. This could be velocity or even a flow metric like Throughput. I will cover flow metrics in Chapter 9, “Improving Flow.”

• ■   Availability   A shared understanding of the Developers’ general availability/capacity during the Sprint. This takes into consideration training, travel, vacations, holidays, etc. This does not need to be detailed or the result of traditional capacity planning. In fact, using the term “availability” instead of “capacity” helps the Developers distance themselves from this command-and-control (C&C) waterfall practice.

• ■   Retrospective commitment(s)   Implementing one or more process improvements—as identified in the previous Sprint Retrospective(s). This may take time away from the development.

During Sprint Planning the Scrum Team also crafts a Sprint Goal—to represent the why. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Developers on why it is building the Increment. The Product Goal and the Product Owner’s objective may influence the Sprint Goal, or it may simply become the Sprint Goal.

Sprint Planning has the following outputs:

• ■   Forecast   The selected PBIs that the Developers feel that they can accomplish during the Sprint. The Sprint Backlog contains the forecast.

• ■   Plan   How the Developers will develop and deliver the forecasted PBIs. The plan can be represented in many different ways, including tasks, tests, and diagrams. The Sprint Backlog contains the plan.

• ■   Sprint Goal   An objective that will be met within the Sprint through the implementation of the forecasted PBIs. The Sprint Goal provides guidance to the Developers during the Sprint. The Sprint Backlog contains the Sprint Goal.

By the end of Sprint Planning, the Developers should be able to explain to the Product Owner and Scrum Master how they intend to work in a self-managing way to accomplish the Sprint Goal and create the anticipated Increment.

Sprinting in Azure Boards

Using Azure Boards, a Scrum Team can plan a Sprint, create the Sprint Backlog, and manage their daily work. Developers can also inspect their progress toward the Sprint Goal by tracking that work on the Kanban board or the Taskboard, or by referencing the built-in analytics.

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

• ■   Capture the Sprint Goal.

• ■   Plan a Sprint by creating the forecast and the plan.

• ■   Visualize and update the Sprint plan (using Task work items).

• ■   Take ownership of tasks.

• ■   Track progress using the Taskboard.

• ■   Visualize blocked work.

• ■   Track progress using a burndown chart or the Taskboard itself.

• ■   Move incomplete PBIs back to the Product Backlog.

Creating the Sprint Backlog

The Sprint Backlog is a Scrum artifact. It contains the forecasted PBIs along with the plan for delivering them. It is created during Sprint Planning, but the plan will continue to emerge throughout the Sprint. In Azure Boards lingo, the Sprint Backlog contains those PBI work items that have their Iteration set to the current Sprint and any related Task work items that represent the plan.

Note There are many ways Developers can formulate their Sprint plan. The Scrum Guide is silent on this. Tasks are a very popular way to express a plan, but so are failing acceptance tests, workflow states modeled on a Kanban board, diagrams, and even conversations. In this chapter, I will show you how to use tasks (Task work items) as a way to express a Sprint plan. In Chapter 7, “Planning with Tests,” I’ll explain how and why Developers may want to graduate to expressing their plan as failing acceptance tests (using Test Case work items).

In this section, I will show you how to use the various tools in Azure Boards to create the Sprint Backlog.

Creating the Forecast

Assuming that the Developers have already come to a consensus on what feels like the right amount of work, the act of forecasting the PBIs in Azure Boards is straightforward. In fact, there are only two options you have to set to make in order to forecast a PBI work item:

• ■   Set Iteration to the current Sprint.

• ■   Set State to Forecasted

The easiest way to set Iteration for a PBI work item is to drag it from the Product Backlog to the current Sprint in the Planning pane. You can see this in Figure 6-1. After you drop the item, Iteration will be updated. You can also set Iteration manually and get the same result—which will help users with only a Stakeholder access license.

FIGURE 6-1 Forecast a PBI by dragging it to Sprint 1 in the Planning pane.

Note If the current Sprint is not visible in the Planning pane, it’s because it hasn’t been created yet or it hasn’t been selected by the team. Rather than go to Project settings, you can use the shortcut in the Planning pane to add a new Sprint (or select an existing one). Whether or not you use the shortcut, being able to select just the Sprints a team wants is a nice feature that keeps the list of Sprints short and manageable in the Planning pane.

Once a PBI work item’s Iteration is set to a Sprint, it will become visible in that Sprint Backlog. Further, when the State of the PBI work item is changed to Forecasted, the work item may disappear from the Product Backlog page. This behavior can be controlled by setting the In Progress Items option, as you can see in Figure 6-2. I don’t like seeing In Progress Items in the Product Backlog, so I keep this option cleared. You may have a different preference.

FIGURE 6-2 We are disabling the In Progress Items option in the Product Backlog.

Tip To remove a PBI work item from the forecast (also known as deselect or descope), just drag that work item to the top node in the Planning pane. This node represents your team’s Product Backlog (for example, Fabrikam Team Backlog) and will reset Iteration back to the root value, indicating that the item is no longer forecasted. You can also reset the Iteration value manually. You will also need to reset the work item’s State field. Although you can remove a PBI from the Sprint at any time, even after Sprint Planning, ideally all forecasted PBIs will be completed, according to the Definition of Done, and never return to the Product Backlog—because they will have their State fields set to Done at that point.

The other step in forecasting a PBI work item is to set its State to Forecasted. This signals Azure Boards that the PBI is now planned—for the sake of analytics. Simply dragging to the current Sprint does not do this for you automatically—which is actually a good thing. Sometimes the Developers will bring many (maybe too many) PBIs into the Sprint, have a conversation about which items to forecast, and then set those to the Forecasted state. The others would be deselected for that Sprint. You will need to update the PBIs manually by opening each work item one at a time and setting State to Forecasted. For a large number of items, you can use the bulk-modify feature to multi-select and change their State fields in a single operation.

From the perspective of Azure Boards, once the Iteration and State fields are set, those PBI work items are forecasted for that Sprint. Your primary tool for viewing and managing them is now the Sprint Backlog.

Fabrikam Fiber Case Study

Typically, Paula (the Product Owner) is the user who edits the items in the Product Backlog, setting the Iteration and State fields accordingly. Other Scrum Team members have done this in the past as well, and they are all capable of doing it. These changes are done during Sprint Planning.

Forecasting Based on Past Performance

If the Developers have completed multiple Sprints, they can start to use their empirical data to improve forecasting. In other words, the Developers can review how many PBIs they have completed in previous Sprints—according to their Definition of Done. This measure is known as velocity, and it can be used as an input to Sprint Planning.

Velocity is a complementary practice and is the most popular way Scrum Teams measure their past performance. It relates to how much PBI effort/size the Developers can develop and deliver in a single Sprint. Velocity is the sum of those effort/size points for PBIs done—according to the Definition of Done—for a Sprint or series of Sprints. Once established, the Developers’ velocity can be used to forecast Sprints and plan releases. Velocity is most accurate when the team composition, Sprint duration, Definition of Done, domain, and estimation practices remain constant.

Note I’m often asked how velocity can be meaningful when PBIs are estimated using such crude precision and in such abstract values as story points. Fortunately, it is. Thanks to the wisdom of the crowd, the law of large numbers, and relative sizing, the average of the results obtained from a large number of trials (Sprints) should be close to the expected value and will tend to become closer as more trials are performed. Remember, though, the goal of estimating is not the number—it’s the conversation and learning that accompany it.

A key piece to maintaining an honest and consistent velocity is having a stable Definition of Done and sticking to it. It may seem like a small thing, but a Definition of Done is used to establish transparency as to when work is complete—and, as a corollary, when it is not. Without a consistent meaning of done, velocity cannot be measured.

A Definition of Done also helps ensure that the Increment is of high quality, with minimal defects. Professional Scrum Teams will expand their Definition of Done over time. They know that these changes may affect their velocity for a short period of time, but the quality improvements are worth it. Depending on the types of changes made to the Definition of Done (such as adding automated testing), productivity—and, as a corollary, velocity—should improve as well. This is a part of continuous improvement, which I will discuss in Chapter 10, “Continuous Improvement.”

Smell It’s a smell when I see Developers only use velocity to forecast their work. It’s also a smell when I see Developers only use availability/capacity to forecast their work. Professional Scrum Developers use all Sprint Planning inputs as data points for a rich conversation on what feels like the “right” amount of work to forecast.

There are several practices that, if adopted, can improve the Developers’ productivity and, by extension, their velocity. Here is a partial list:

• ■   Establish a right-sized, cross-functional team of Developers.

• ■   Keep team membership consistent.

• ■   Keep Sprint length consistent.

• ■   Remove identified impediments.

• ■   Keep a refined Product Backlog.

• ■   Execute as a team (swarming, pairing, mobbing, etc.).

• ■   Create and run tests early (also known as shift left).

• ■   Build, deploy, and test continuously.

• ■   Avoid generating technical debt.

• ■   Avoid meetings beyond those defined by Scrum.

• ■   Avoid starting work on a new PBI before finishing work on a previous one.

• ■   Avoid multitasking and interruptions.

• ■   Inspect, adapt, and improve continuously.

• ■   Learn from your mistakes.

For Developers new to Scrum, after the team has completed a few Sprints, average velocity should begin to stabilize and become more valuable. In Azure Boards, you can find the team’s velocity on the Analytics page. Figure 6-3 shows a Velocity chart generated from the prior nine Sprints. The Velocity chart can be configured to show a count of PBI work items, a sum of Business Value, a sum of Size/Effort, or a sum of Remaining Work.

FIGURE 6-3 Azure Boards provides informative analytics, such as the Velocity chart.

The color of the vertical bars on the Velocity chart indicates the type of work in the Sprint:

• ■   Dark green   Represents completed work (PBI work items set to Done prior to the Sprint end date).

• ■   Light green   Represents completed work (PBI work items set to Done after the Sprint end date). This is a smell that should be discussed by the team.

• ■   Dark blue   Represents incomplete work (PBI work items still set to Forecasted). Ideally a Professional Scrum Team wouldn’t show any Incomplete work because, after the Sprint, they would move incomplete PBIs back to the Product Backlog by setting the Iteration back to the root value.

• ■   Light blue   Represents planned work (PBI work items assigned to a Sprint prior to the Sprint begin date). This includes work that was moved to a different Sprint after the start of the Sprint. Ideally, a Professional Scrum Team wouldn’t show any Planned work because they don’t pre-bucket work into future Sprints.

Tip The Velocity chart provides an average velocity based on a simple average of the Sprints being displayed. Your team may want to compute this differently, based on fewer Sprints, more Sprints, tossing out highs/lows, and so forth. In other words, don’t assume you have to use Azure Boards’ average.

Fabrikam Fiber Case Study

The team’s velocity seems to have normalized around 21. This has been the average of their last few Sprints. They will use a range of 17–25 as they have probabilistic conversations with stakeholders. They are also just starting to play with Kanban as a complementary practice. Down the road, they will consider using flow analytics, such as Throughput, to help forecast their work.

Forecasting Using the Forecasting Tool

As I explained in the last chapter, the Forecasting tool helps visualize a release plan in real time, directly on the Product Backlog. The same tool can be used to assist in Sprint Planning as well. By specifying a value for the team’s velocity, the Forecasting tool shows which items in the backlog can be completed within that Sprint.

You can enable the Forecasting tool on the View options pop-up. After enabling it, you’ll need to provide a velocity number. As you can see in Figure 6-4, I’ve entered a velocity of 21. Azure Boards then adds a Forecast column and displays horizontal lines to the backlog. The Forecast column shows the Sprint that the tool predicts the PBI work item will be developed in.

FIGURE 6-4 The Forecasting tool can help identify which PBIs might be selected for the current and future Sprints.

The Forecasting tool shows only future Sprints. There will typically be some PBI work items at the top of the backlog that don’t appear to be in a Sprint. This is because the tool considers them candidates for the current Sprint. Items that fall between two forecast lines are considered candidates for the Sprint named on the top line. Also, the Forecasting tool ignores PBI work items set to Forecasted. To minimize confusion, you should hide the In Progress Items when using the Forecasting tool.

The Forecasting tool is not based on magic. In fact, its algorithm is quite simple. It walks down the ordered backlog, adding up the size/effort points of each item. Once the sum is greater than the provided velocity, it increments the Sprint number on the horizontal line. When it’s out of work items or Sprints selected by the team, it stops.

Smell It’s a smell when I see a team blindly follow what the Forecasting tool suggests. I’ve even seen feature requests on Microsoft’s Developer Community asking for the Forecasting tool to auto-assign those PBIs into respective Sprints. Please, no! Remember, velocity is just one of many inputs to Sprint Planning.

You may encounter one issue with the Forecasting tool: if it finds a PBI with a size that is greater than the provided velocity, rather than skip it, flag it, or convert it to a Feature work item, the Forecasting tool assumes that the Developers will start on it in one Sprint and then carry it over and finish it in the next Sprint. For example, with a velocity of 15, if a PBI has a size of 21, the tool will carry over 6 points of effort/size to the next Sprint. Professional Scrum Developers don’t start work that they know they cannot finish. Those large PBIs are not ready and would need to be split prior to being forecasted. This would most likely occur during Product Backlog refinement.

Tip Run your low-, medium-, and high-velocity numbers through the Forecasting tool to get an idea of the range of PBIs that could be forecasted for the Sprint. For our Fabrikam Fiber case study, this means running it for a velocity of 17, 21, and finally 25. The difference between low and high can result in a substantial variation in the number of PBIs to consider. All of these PBIs should be discussed during Sprint Planning.

Fabrikam Fiber Case Study

When the team was first learning Scrum, velocity meant everything. It was their only metric and they idolized it. They would try to improve it each Sprint. As the team improved, they learned that velocity is a measure of output, not outcome. Delivering business value in the form of working product is the most important metric. The team still uses velocity but only as one of several inputs into Sprint Planning. They now just forecast the number of PBIs that feels like the right amount of work, given all of those data points. Paula still uses velocity and the Forecasting tool for release planning.

Forecasting Using the Capacity Tool

One of the inputs to Sprint Planning is the expected availability of the Developers during the Sprint. This will vary from Sprint to Sprint, based on factors such as training, travel, vacations, and holidays. Availability is just another data point the Developers should consider when determining how many PBIs to forecast. In other words, if availability is low, the Developers should forecast fewer PBIs than normal, and vice versa.

As much as I want Developers to be able to have a collective feeling of their availability, neophyte teams may need some tooling to help visualize this. For those teams, they might consider the Capacity page in Azure Boards to better determine their availability. The Capacity page allows individual Developers to track their days off as well as their daily capacity. Team days off can also be specified, and they will apply to all Developers—as you can see at the bottom of Figure 6-5.

FIGURE 6-5 The Capacity page allows a team to track their daily availability and days off.

Tip If your team decides to use this tool, don’t waste time setting the Activity type. Rather than specify Deployment, Design, Development, Documentation, Requirements, or Testing, just leave it set to Unassigned. Doing so will save time. It also stops reinforcing that certain people only do certain work. Professional Scrum Teams strive for all Developers to be T-shaped—which are individuals who do more than just their specialty. I’ll talk more about the concept of T-shaped in Chapter 8, “Effective Collaboration.”

Once availability and capacity have been entered, the Work details pane can be displayed as the Sprint Backlog is created. The Work details pane features visualizations that show the total hours of planned work compared to the capacity of the team and the individual Developers. Work details can be displayed for the overall team, by activity, or by individual. Since Professional Scrum Teams don’t track capacity by activity or preassign tasks to Developers, only the top, team-level visualization might be of value. The other sections can be ignored and even collapsed, as I’ve done in Figure 6-6.

FIGURE 6-6 The Work details pane shows hours planned vs. capacity.

Smell It’s a smell if I see a team using capacity planning tools of any kind. Though it might be helpful for teams new to Scrum to avoid forecasting too much work, Professional Scrum Teams recognize traditional capacity planning as a source of waste and potential dysfunction. They are already aware of their daily availability and upcoming days off, and they will use that as an input when forecasting a comfortable amount of work for the Sprint. Planning capacity by individual or activity type is counter to the self-managing attributes of the team. Let the Developers decide what seems like the right amount of work, what to work on next, and who should do what type of work. Let them do this as late as is responsible during the Sprint.

Capturing the Sprint Goal

One of the outputs of Sprint Planning is the Sprint Goal. It may have been an input as well, but assuming it wasn’t, the Scrum Team will need to collaborate and craft one. The Sprint Goal is an objective set for the Sprint that can be met through the implementation of the forecasted PBIs. It provides guidance to the Developers on why they are building the Increment and gives some flexibility regarding the functionality implemented within the Sprint. The selected PBIs deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any coherence that causes the team to work together rather than on separate initiatives.

Unfortunately, there is no “first-class” support for capturing a Sprint Goal out-of-the-box in Azure DevOps. Previous versions of the Scrum process had a Sprint work item type that included Sprint Goal and Sprint Retrospective fields, but this work item type is no longer part of the Scrum process. The wiki is an obvious place to capture a Sprint Goal. A Scrum Team could create a dedicated page for all its Sprint Goals or separate pages for each Sprint. The problem with using the wiki is that the Scrum Goal is a long way away from the Sprint Backlog and Taskboard in the Boards hub.

Smell It’s a smell when a Scrum Team does not have a Sprint Goal. Yes, it’s difficult to craft a good goal, especially when the forecasted PBIs span many areas and capabilities and might even contain a bug fix or two. Having a goal, however, gives the Developers something to focus on and commit to. It’s also good for people to have goals. Professional Scrum Teams understand the psychological value in having a Sprint Goal, working toward it, and achieving it.

A Scrum Team can also install and use the Sprint Goal extension by Kees Schollaart. This extension allows a Scrum Team to capture the Sprint Goal and keep it visible within Azure Boards as a way for the team to keep focus on the goal. The Sprint Goal extension can be configured each Sprint with that Sprint’s goal and display it as the Goal tab’s label, as you can see in Figure 6-7. As the Developers interact with the Sprint Backlog and Taskboard, the Sprint Goal is visible at all times. This extension can be used in addition to the wiki.

FIGURE 6-7 The Sprint Goal extension keeps the goal front and center during the Sprint.

Note The Sprint Goal doesn’t have to be captured electronically—it can be written on a whiteboard in the team area or another public place. The advantage of using an electronic format is that it can be shared with team members and stakeholders outside the office. A list of past Sprint Goals can be maintained as well, for reference, in the wiki.

Fabrikam Fiber Case Study

Paula and the Developers craft the Sprint Goal together. She usually has a business objective in mind prior to Sprint Planning, but in some Sprints a goal is crafted around the forecasted PBIs. Either way, the Sprint Goal has been recorded in the corresponding Sprint page in the wiki. Andy just installed the Sprint Goal extension, so they will start displaying the Sprint Goal there as well.

Creating the Plan

The forecast and Sprint Goal are only two of the three outputs of Sprint Planning. The Developers must also identify the plan for implementing the forecasted items. Although the plan should be created during Sprint Planning, it will also continue to emerge throughout the Sprint.

For some teams, the plan may have begun to emerge in the weeks prior to Sprint Planning, during Product Backlog refinement. These ideas should be captured in some easy, low-fidelity format such as notes or whiteboard photos, rather than as any kind of work items. Plans change and the latest responsible moment for creating an actionable plan is during Sprint Planning. Not only does this allow the Developers to create a plan with the latest information available, but it also reduces waste.

In Azure Boards, the plan is typically represented by Task work items. This emerging hierarchy of work items can be seen and managed in the Sprint Backlog and Taskboard. From the Sprint Backlog, you can create and associate Task work items for each PBI work item, as you can see in Figure 6-8. The new Task work item will default its Area and Iteration to that of its parent PBI. The Developers should also provide a short, meaningful Title and, optionally, Remaining Work (in hours) at a minimum. Additional details can be entered in the Description field.

FIGURE 6-8 You can add an associated Task work item in the Sprint Backlog.

Tip Estimating the duration of tasks is optional. If the Developers decide to do it, they should estimate as a team. As estimates are made, it should not be assumed that any particular Developer will be doing any particular piece of work. In other words, don’t let the Developer with the best skills for completing a specific task provide the estimate for that task. During development, it might be the case that someone else ends up doing the work. Once a Developer owns the task, they should reestimate the remaining work regularly until it is done. The estimate variability of having specialists and generalists work on tasks should be a wash because some team estimates will be lower and others will be higher.

As the Developers formulate their plan, it’s best to leave the Assigned To field blank. Since all the work will be done after Sprint Planning, knowing who will be performing each task is difficult. Some teams may prefer to leave Sprint Planning with each Developer having at least one task to get started on. I will cover this in detail in Chapter 8.

Tip Consider not having Azure DevOps up and running during Sprint Planning. The absence of any electronics and tools will increase focus. Keystrokes and mouse clicks can interrupt a productive conversation. Sticky notes or whiteboard notes can be converted to work items after Sprint Planning.

Fabrikam Fiber Case Study

The team likes to work on sticky notes or a whiteboard during Sprint Planning. This way, changes to the plan can be made quickly and easily. Toward the end of the meeting, those notes are converted to Task work items.

Work planned for the first days of the Sprint by the Developers should be defined by the end Sprint Planning, often to units of one day or less. It is common for only 50 to 80 percent of the total plan to be identified during Sprint Planning. The rest should be at least “stubbed out” for later detailing or given rougher estimates that will be decomposed later in the Sprint. The act of decomposing work implies that the Developers have a consensus on how the work will be accomplished. Professional Scrum Developers are good at reaching consensus because they operate by the Scrum Values, especially courage and openness in these situations.

Note I get pushback from some Developers who think that creating Task work items is waste. Before I share my opinion with them, I like to find out more about their team. If they are a high-performance team—with PBIs that take only a day or two to complete—then perhaps they don’t need to break work down and track individual tasks. They can decide—in real time—how to decompose, execute, track work, and assess progress.

I explain that there are broader benefits to creating and tracking work items. As the Developers work, their code and other artifact commits can be associated with these work items to enable traceability all the way through to a build and even a release. This is important to the Product Owner and stakeholders, as well as your fellow Developers, who want to trace which work was implemented by which commit, included in which build, and deployed with which release. Traceability in Azure DevOps is bidirectional so that a change in a release can be traced back to the work item(s) to explain why the change was made. Developers new to Scrum can also use this information to learn what they are actually capable of and to improve their confidence for the next Sprint.

When creating a plan for a PBI, do what works for the Developers: consider decomposing along design seams. The goal is to achieve independence from other tasks as much as possible. In other words, you should try to avoid interdependencies, and thus blocking tasks. Initial blocking tasks are those that have to be done first, usually by a single Developer (or a pair), and they prevent a majority of work from moving forward until they’re complete. Ideally, each Developer (or pair) can work on separate tasks in parallel and make meaningful progress when those tasks are done.

Here are some questions to consider as the Developers create their plan:

• ■   Does this task provide a meaningful step toward the completion of the PBI?

• ■   Does this task have criteria for being done (either explicit or implicit)?

• ■   Can this task be worked on by a pair of Developers effectively?

• ■   Can this task be worked on by a mob (all Developers) effectively?

• ■   Does this task depend on any other tasks being done first?

• ■   Do other tasks depend on this task being done first?

• ■   Can this task be completed in one day or less?

• ■   Has anyone else created this task already?

• ■   Is this task done already?

Remember, tasks are what you actually must do during the Sprint. They include work across all disciplines: analysis, design, coding, database, testing, documentation, deployment, security, operations, and everything else. The tasks must bring together everything required from the perspective of completing the PBI (according to the Definition of Done) as well as the product’s quality needs and the practices of the people doing the work. In other words, completion of all tasks should result in the Definition of Done being met for that PBI. You can see an example of just such a plan starting to emerge in Figure 6-9.

FIGURE 6-9 This example plan is represented by tasks in the Taskboard view of the Sprint Backlog.

Fabrikam Fiber Case Study

The Developers have become quite good at envisioning the plan at the Product Backlog refinement sessions, finalizing it during Sprint Planning, and then creating a representation of it using Task work items. New Task work items are created during the Sprint as the plan evolves and changes.

Sprint Activities

What the Developers should be doing in-between Sprint Planning and Sprint Review is deliberately vague in the Scrum Guide. It doesn’t even have an official name—it’s simply called “development.” This ambiguity is by design. Scrum is just a framework. Besides meeting for the Daily Scrum and ensuring that progress is inspected, the Developers are on their own to manage and execute their own work throughout the day—which is how self-management should be.

Once the Sprint has been planned, the Developers should begin executing against their plan. If the plan was expressed using Task work items, then the Developers should begin working on these tasks. It is important to make progress toward the Sprint Goal on a daily basis so that, by the end of the Sprint, the Developers will have accomplished what they set out to do. Azure Boards includes a number of tools that can help Developers manage their Sprint and track its progress.

Developers can use the Taskboard to help visualize the work in progress, what work has been done, and what work remains. The Developers can use the Taskboard collectively or individually, as each person tracks their work and the overall work for the team. The Developers can also use the burndown and other charts to review the state and rate of progress. All of these analytics are calculated automatically by Azure DevOps. As the Sprint progresses, these calculations and tools can be used to decide whether to adjust plans, add more work, or make changes to help deliver a Done Increment of the product.

The rest of this chapter includes those Scrum-related activities that the Developers need to perform throughout the development portion of the Sprint. I’ll relate those activities back to the respective tools in Azure DevOps.

The Daily Scrum

As I mentioned in Chapter 1, the Daily Scrum is a 15-minute, timeboxed meeting for the Developers to synchronize their activities and create a plan for the next 24 hours. It allows Developers to listen to what other Developers have done and are about to do. This meeting leads to increased awareness, collaboration, and even accountability. Developers make plans at this meeting, and these plans and their outcomes will be inspected 24 hours from now.

The Developers should use the conversations during the Daily Scrum to assess their progress. By hearing what is or isn’t being accomplished each day, the Developers can determine whether they are on their way to achieving the Sprint Goal. As Developers improve in their collaboration, this vibe will become more noticeable—even outside the Daily Scrum. High-performance teams may even outgrow the need for a tool, such as a burndown chart, to help them assess progress. A team’s conversations and intuition might suffice instead. Any method they choose should be transparent to the team.

Handling Impediments

During the Daily Scrum, someone might raise an impediment. An impediment is anything that blocks or slows down the progress of the team toward achieving the Sprint Goal—that cannot be easily removed by the team. Impediments are different than challenges, which tend to be smaller and able to be resolved quickly. Challenges are just part of everyday life when working in a complex environment.

Impediments are usually external and require some collaboration with others in the organization to resolve. In these cases, a Professional Scrum Master might be required to resolve them. In any case, impediments must be cleared in order for the team to resume productivity. In Scrum, there are two formal opportunities to identify impediments—at the Daily Scrum and at the Sprint Retrospective. That said, impediments can occur at any time and the Scrum Team should be ready to mitigate them.

Tip Remove impediments—don’t manage them! Successful complex product development hinges on the ability to inspect and adapt. If impediments are identified but are not being removed, the Scrum Master must become more actively involved. They may also need some additional authority.

If the Developer experiencing the blockage cannot remove the impediment themselves, another Developer should offer to help. If necessary, the Scrum Master should facilitate its removal and ensure that it happens. As a last resort, the Scrum Master should take ownership of the impediment and remove it.

Impediments that surface during the Daily Scrum should be briefly discussed. Problem-solving discussions detract from the real purpose of the Daily Scrum. Although not all impediments are the same size or complexity, they should be removed as early as possible. A Developer shouldn’t wait until the Daily Scrum to raise the issue if they are completely blocked. Remember that it’s more than okay to talk to people at any time during the day!

Smell It’s a smell when I hear Developers repeatedly telling one another that they have no impediments. Developing a product like software is a complex process fraught with risks and the potential for problems every day. Work like this can regularly yield impediments. In my experience, Developers tend to be optimistic, problem-solving individuals, and in their opinion, nothing ever blocks them. They have lots of (other) work they can be doing. This attitude is more common on teams new to Scrum where Developers might be hesitant to reflect the Scrum Value of openness and to share their problems openly. Professional Scrum Teams know that it’s about the team, not the individual. Professional Scrum Developers ask for help, raise impediments early, and are transparent about progress. This attitude represents the Scrum Value of courage.

If the impediment cannot be resolved immediately, an Impediment work item can be created in Azure Boards. You can see an example of this in Figure 6-10. Tracking impediments in this way is not a requirement, especially if the Scrum Team works to resolve them quickly. The team may decide to link the new Impediment work item back to the related Task or PBI work item that is affected by the impediment. In addition, Task work items can be marked as Blocked (or tagged as Blocked) so that they will stand out on the Taskboard. Although these extra steps provide context, they should be used only if the team decides there is value in tracking the additional detail.

FIGURE 6-10 Here’s an example of an Impediment work item.

As I mentioned in Chapter 3, open impediments can be tracked by creating and running a shared work item query. This query would return all Impediment work items with a State of Open—which are the unresolved impediments. Once an impediment is resolved, its State should be changed to Closed and it will disappear from the query results.

Tip Managers and other leaders should regularly query the list of open and closed impediments. It’s important to make this list transparent to the right people. Doing so provides a view of not only what organizational changes have taken place (closed impediments), but also what improvements are planned (open impediments) and which ones might require their intervention and authority. Seeing indicators that the team is improving can be as powerful as seeing the product improving.

Fabrikam Fiber Case Study

The Scrum Team has very few open impediments. The Developers have become quite good at removing them quickly. Because of this, they don’t have many Impediment work items and none that are currently blocking specific work items. Regular team communication keeps everyone aware of the current issues and what might be blocked.

Decomposing Tasks

Work planned by the Developers should be decomposed into units of one day or less. If the Developers are using tasks, then a task should be small enough to be completed in a single day—whether by a single Developer, a pair, or a mob. This constraint forces Developers to create more specific, granular, atomic tasks that elevate efficiency by reducing bottlenecks and risks. By pursuing smaller units of work, Developers can take complex problems and decompose them to a level of detail that they can more easily understand and achieve. Smaller tasks also lead to improved transparency, improved opportunities to swarm, and a more accurate assessment of work remaining. I’ll talk more about swarming on tasks in Chapter 8, “Effective Collaboration.”

Assuming the one-day task size limit, you might find stubbed-out “epic” tasks in the Sprint Backlog, especially if placeholder tasks were created in Sprint Planning. Similar in concept to epic PBIs, these are tasks that are too large to be completed in a single day. Such tasks should probably be decomposed.

Developers new to Scrum may try to plan the tasks for their entire (eight-hour) day’s capacity. Doing so is not realistic, and it usually results in waste. People take breaks, check email, have impromptu meetings, and perform other activities that distract from their Sprint Backlog work. With these factors in mind, Professional Scrum Developers may even want to decompose tasks that are larger than six hours, or even four hours.

Smell It’s a smell when someone asks me how to track the original “epic” task. I understand that they want to establish a visual breakdown of the work, which can be helpful for teams new to Scrum. With complex work, the plan is fluid. This is why Scrum considers planning an (ongoing) activity and not a document. In other words, planning is more important than plans. If you need to split a large task into two or more smaller tasks, just rename the original large task, or delete it when you are done. This keeps the Sprint Backlog lean. Also, burndown analytics will be more accurate without a bunch of inert tasks in your Sprint Backlog. Remember, the Sprint Backlog is by the Developers, for the Developers, and nobody else should be seeing it, updating it, or caring about how work breaks down during the Sprint.

As the Sprint progresses and development work unfolds, the Sprint Backlog will become more refined as those “epic” tasks are shed. In other words, the Developers should break down large tasks as they work. For example, there shouldn’t be any 16-hour tasks titled “Develop it” in the Sprint Backlog toward the end of the Sprint.

I’m often asked about sequencing tasks when there are interdependencies. For example, “Create acceptance tests” must be done before “Run acceptance tests.” The Task work item does have a hidden Backlog Priority field, much like the PBI work item. The Taskboard displays Task work items ordered by this field, much in the same way the Product Backlog does. A sparsification background process will assign the Backlog Priority as tasks are dragged and dropped into a different sequence.

Smell It’s a smell when I see Developers spending time sequencing their tasks. The smell has a hint of waterfall and also command-and-control. It could be that the work is so new and so complex that the Developers really do need to organize the tasks in a particular order. Hopefully this is not the case, or at least not the norm. In my experience, Professional Scrum Teams are able to figure out which task to perform next through conversation and collaboration, without having to have someone else sequence the work.

The Taskboard

The Taskboard in Azure Boards is a collaborative tool used by the Developers to communicate and execute their Sprint plan. It’s pretty awesome. It provides visibility into what work is in progress, what work has yet to be started, and what work is done. Developers can quickly assess progress by viewing the Taskboard. You can think of the Taskboard as an information radiator. It’s always on and (hopefully) updated regularly.

Note The Taskboard is not a reporting tool. It’s not meant to be used by management to hold the Developers accountable for their progress. In other words, it should not be used as a “blame board.” If these behaviors start to surface in an organization, the Developers will be less inclined to be honest and transparent about the tasks they are working on. The fear is that they will revert to their old ways and focus on making the burndown look good, even if that means stretching the truth. This is why the Sprint Backlog, how the Developers work, and the tools that they use are for their eyes only.

Unlike the Product Backlog and Sprint Backlog, the Taskboard is two-dimensional, much like the Kanban board. The forecasted PBI work items are listed down the left side, with the associated Task work items listed to the right. Across the board, their associated Task work items can be in one of three states: To Do, In Progress, or Done. The Taskboard also summarizes the total amount of Remaining Work for all tasks within each column.

The Taskboard displays PBI work items that are assigned to the current Sprint. You can view Taskboards from previous Sprints as well. These PBIs can be in any State (other than Removed), although they will primarily be in the Forecasted or Done state—if you are following guidance from both me and Microsoft. In other words, you shouldn’t see any New or Ready PBIs in the Taskboard. The PBI work items don’t have to have any associated tasks to be displayed, either. Actually, the Taskboard is a great place to start adding associated tasks.

If a PBI work item is assigned to another Sprint but has linked tasks in the current Sprint, you will also see them listed here. Unassociated tasks are displayed on the board in an Unparented section. Hopefully you won’t have any of these, because Professional Scrum Developers should only be doing work on the forecasted PBIs in order to meet the Sprint Goal. An exception to this guidance would be the inclusion of a process improvement identified in the previous Sprint Retrospective that, though important, doesn’t necessarily have to be visualized as Task work items.

Smell It’s a smell if there are any PBI work items listed on the Taskboard that are not set to the current Sprint. It’s also a smell if any of the associated Task work items are from a different Sprint. It could be that this was a one-time missed forecast and carryover of work, but it might be systemic. Professional Scrum Developers don’t carry over unfinished PBIs to the next Sprint as a rule but instead improve their practices to meet their forecasts.

By default, the Task work item cards show the work item ID, Title, Assigned To, State, Remaining Work, and any Tags. These default fields can be removed and new fields added in the Taskboard settings. For example, you may want to remove the State field from the cards, because you’ll be able to see its State based on which column it is in.

Here are a few points of guidance for creating and managing Task work item fields:

• ■   Title   Provide a short, meaningful title that quickly summarizes what this task represents. Two- or three-word titles work best (“Create tests,” “Create pipeline,” “Create artifact feed,” etc.).

• ■   Assigned To   Leave tasks “unassigned” until a Developer drags it to the In Progress column. If an unfinished task is dragged back to the To Do column, remove the Developer’s name.

• ■   Remaining Work   Optional, but enter hours in this field. Actionable tasks have a value of 8 hours or less. Remaining work should be reestimated at least once a day. It’s okay if this value increases.

• ■   Tags   Optional, but tags help visualize metadata about tasks (for example, blocked). You can also style the cards based on tags (such as showing blocked tasks in red).

The Developers can update the Taskboard to reflect the status of the Task work items visually by dragging and dropping. Anybody viewing the board can then see the progress that the Developers are making against each PBI. Developers can focus and collaborate on the remaining pieces of work. The board leads to increased transparency, honesty, and accountability.

A number of activities can be performed in the Taskboard:

• ■   View the plan (tasks) for developing the forecasted work.

• ■   Group tasks by PBI or by Developer.

• ■   Filter the Taskboard by Developer, type of task, State, Tag, or Area.

• ■   Style the cards based on rules (such as showing aging tasks in orange and blocked tasks in red).

• ■   Assess progress in a number of ways.

• ■   Add associated tasks to a PBI item.

• ■   Make edits to a specific PBI or Task work item.

• ■   Drag a Task work item to reparent to a different PBI work item.

• ■   Change a Task work item’s State by dragging between columns.

• ■   Change the Remaining Work value.

• ■   Select an older Sprint to view its plan.

• ■   Customize the Taskboard by adding a new column.

In the Scrum process, a Task work item can be in the To Do, In Progress, Done, or Removed state. I did not change this in our Professional Scrum process. The natural progression is To Do ⇒ In Progress ⇒ Done. These three states map to the three columns on the Taskboard. A Task work item can be dragged to one of these state columns. When dropped, the task’s State field will change to that value and be saved automatically. When you drop a task in the Done column, the Remaining Work field is set to 0 (blank) and the field becomes read only.

No column is mapped to the Removed state. If you want to remove a task from the Sprint Backlog, you will have to open it and manually change its state to Removed. You can also simply delete it.

Note The Taskboard, like the Kanban board, supports Live Updates. This means that the Taskboard now automatically refreshes when changes occur. As other Developers add, change, or move cards on their Taskboard, your Taskboard will automatically reflect these changes. In other words, you don’t need to continually press F5 (refresh) to see the latest changes. Live Updates uses SignalR, an open source library developed by Microsoft that allows server code to send asynchronous notifications to client-side web applications.

Smell It’s a smell whenever I see someone outside the team—or even the Product Owner or Scrum Master—changing the Sprint Backlog. Only the Developers are allowed to add, delete, or change the contents of the Sprint Backlog. The Taskboard is fun to use, and sometimes Scrum Masters, Product Owners, or stakeholders want to “play” with it. This is fine—as long as they are making changes according to the Developers’ wishes and not causing them to lose focus.

Fabrikam Fiber Case Study

The Developers use the Taskboard to some degree in each Sprint. They refer to it throughout the day to see what work remains to be done, to see what their colleagues are working on, and to take on new work themselves. Scott (the Scrum Master) uses the Taskboard to keep an eye on the big picture. He watches the amount of work in progress while looking for bottlenecks. Scott’s goal is to coach the Developers to deliver the forecasted PBIs—ideally in the order that Paula wants them.

Viewing Tasks by Developer

The default view in the Taskboard is Task work items grouped by PBI work item. This arrangement provides a simple visualization of the work in progress for each of the forecasted items in the Sprint Backlog. By default, all PBI work items on the left appear with a blue border and Task work items appear with a yellow border. These colors align with the colors of the respective work item icons.

As an alternative, the Taskboard can be configured to see the tasks owned by a particular Developer, or yourself (@me), or those tasks that are unassigned. From the Person drop-down, select the Developer and their card(s) will highlight. You can see an example of this in Figure 6-11.

FIGURE 6-11 You can highlight tasks by individual Developer.

A Professional Scrum Team knows the power of self-management. This means, among other things, that they do not assign work ahead of time. The Developers also know that it’s important to finish work before starting new work and that multitasking is a myth. Therefore, no more than one In Progress Task work item should be owned by any given Developer at any given time. In other words, viewing tasks by developer should not be very helpful for a team practicing Professional Scrum. Even using the Unassigned highlighter should be redundant because those tasks should, by definition, be the only ones that are in the To Do column. It’s probably best to just leave this feature set to All. In other words, you shouldn’t need to use it. That said, the Developers may find some value in showing all of the Done tasks highlighted by Developer—especially for plans with numerous tasks.

There is another way to view tasks on the board by Developer: the Group by People view. You can use this view to pivot the Taskboard to display tasks by Developer, rather than by PBI. This view shows the Developers down the left side of the screen and their associated tasks horizontally to the right, as in Figure 6-12. The first row lists those tasks that are Unassigned.

FIGURE 6-12 You can group tasks by individual Developer.

Ordering cards is disabled when your Taskboard is grouped by people. This means that you cannot drag tasks vertically within the same Developer (or unassigned) in this view. You can drag a task to another Developer or drag a task horizontally between the states. A nice side effect of dragging a task to a Developer is that the Taskboard will automatically set that Developer as the owner of the Task work item.

My aforementioned guidance applies to this view as well. There may not be a lot of utility here for a Professional Scrum Team since only one Task work item should be owned/in-progress at a time per Developer. That said, the Developers may find some value in showing all of the Done tasks grouped by Developer—especially for plans with numerous tasks.

Adding a New Task

As the Developers identify new work or want to decompose larger pieces of work, new Task work items can be created. Ideally, this is done at the beginning of the Sprint, primarily as a result of Sprint Planning. The plan will emerge throughout the Sprint. New tasks will be added. Tasks will be changed. Tasks will be split. Tasks will be deleted. If this is not happening throughout the Sprint, then perhaps your work is not that complex. The Developers always know more today than they did yesterday.

Over time, the Developers will improve in their ability to identify and create the plan—in the form of Task work items—earlier in the Sprint. That said, it will probably never be the case that all tasks can be identified in Sprint Planning, nor should it. The important thing to remember about the Taskboard is that it should honestly and accurately reflect the remaining work in the Sprint, to the best of everyone’s knowledge, at that moment in time.

There are several places in Azure Boards to create a new Task work item, but if the Developers are using the Taskboard regularly throughout the day then it makes sense to create one from that page. Next to each PBI work item, in the To Do column, is a large icon you can click to add a new item, as you can see in Figure 6-13. When you click this icon, a new task card appears, allowing you to add a title. This can be done in rapid succession as the Developers brainstorm a plan in real time. The Task work item’s Area, Iteration, and Related Work link are all defaulted to the associated PBI work item’s values.

FIGURE 6-13 You can add a new Task work item in the Taskboard.

After the Task work item has been saved, you can quickly update the other visible fields (Assigned To, Work Remaining, etc.) on the card. Remember, it’s best to leave the Task work item unassigned, unless you or another Developer will begin working on it right away. Clicking the title opens the Task work item form so that you can set other fields, such as Description.

Tip It’s best to add tasks as the result of a conversation with all Developers, as in Sprint Planning. If, during development, this is not possible, it’s valuable to have another Developer (or two) review new tasks and changes to the plan. This is especially important if the plan has substantial complexity. Developers should also quickly assist in estimating the effort required to complete the task. These estimates can be adjusted later when more information is known. Changes to the plan should be discussed at the next Daily Scrum.

Taking Ownership of a Task

During the Sprint, the Developers work the plan in order to achieve the Sprint Goal. What this looks like is very context specific and will vary from team to team and product to product. If the Developers are using tasks to represent their plan, then they will complete those tasks in order to achieve the Sprint Goal by developing and delivering the forecasted PBIs.

Professional Scrum Developers may detail out the tasks for the first few PBIs but may also broadly identify tasks—at least at a high level—to be broken down later for the remaining PBIs in the forecast. Teams just getting started with Scrum might find themselves still working out the plan (that is, identifying tasks) well into the Sprint. All teams will do this to some degree. Being able to envision and capture the plan before starting the actual work is a skill that comes with the experience of working together as a team, on the same domain, using the same tools and the same practices.

Task ownership is not a required outcome of Sprint Planning. In fact, it’s important to leave To Do tasks unassigned so that Developers who have availability can pick a relevant task to work on next. In Scrum, work should not be directed or assigned. In other words, when creating or updating a task, don’t assign it to anyone who doesn’t request—or at least wish to own—that piece of work.

You should also resist the urge to assign tasks to the ideal Developer for the task ahead of time. Doing so will decrease collaboration and the opportunity for other Developers to learn. When the time is right, the Developers decide who will take on that task. This decision takes many factors into account, including the background, experience, and availability of the candidate Developer. More than likely it will be the ideal Developer because that’s a recipe for a great product. Professional Scrum Developers know that selecting and taking ownership of a task should not be based on what task they want to do next, or what task they feel they are best suited to do, but what task needs to be done. If possible, they should take ownership of the next most important task, as determined by the team, required to complete the current PBI before moving on to the next one. This is a hard but important discipline.

Note Fellow Professional Scrum Trainer Benjamin Day says preassigning a task is like “licking a cookie and putting it back on the plate”—nobody else will want to touch it after that. If you exit Sprint Planning with your name on a bunch of tasks (or even PBIs), you have essentially licked those cookies. A fresh plan of tasks is like having a plate of fresh cookies. They look delicious, so you grab one and start eating. You finish that cookie and decide that you want another one. But you find out that, in the interim, someone else came through and licked a bunch of them. In that rogue cookie-licker’s defense, they’re licking just the cookies that they fully and honestly intend to eat. Nevertheless, what are the chances of you eating one of those licked cookies? Probably zero—same as the chances of you working on a task with someone else’s name on it.

Remember that the purpose of the Daily Scrum is to identify the plan for the next 24 hours. This means that Developers, at least once per day, synchronize on what tasks each will be working on or pairing up to work on. The Developers can then go and take ownership of those Task work items in question. Taking ownership, as well as changing ownership, can happen at any time during the day, and even multiple times per day.

Tip Having Azure Boards up during the Daily Scrum can distract from the Developers’ ability to collaborate and create a plan. Worse, it can turn the Daily Scrum into a “board walk” status meeting. Someone—possibly the Scrum Master—should keep an eye on this, and even suggest turning devices off as an experiment. If conversation, collaboration, and planning improve, the experiment will have proven itself.

Ironically, in Azure Boards, ownership is tracked using the Assigned To field. When the time is right, the Developer who will be performing the work should change the entry in the task’s Assigned To field to their name. They can ask another Developer to do it as well. In the Taskboard, you can take ownership of a task by clicking in the “assigned to” area of the card (by default, this area shows the label Unassigned). From the resulting drop-down list, select a user or reset the task back to Unassigned, as you can see in Figure 6-14. Task ownership can also be set by opening and editing the Task work item directly.

FIGURE 6-14 A Developer can take ownership of a task in the Taskboard.

When selecting a Developer from the drop-down list, please keep these considerations in mind:

• ■   A work item can be owned only by a user who has been added to a project.

• ■   When you’re selecting a user from the Taskboard, the drop-down list reflects members of that team only.

• ■   You may have to first search for a specific Developer before being able to select them. Over time, the drop-down list will display those users that you have most recently selected (your Developers).

• ■   A work item can be owned by only one user at a time. If a pair or mob is working on the task, then just pick one of them to be the owner. If it’s a large “epic” task, then break it down first. If this one-owner limitation concerns you, I have to say that is a smell of a command-and-control (C&C) mindset or possibly valuing output over outcome. Let’s focus on getting done, achieving the Sprint Goal, and delivering value instead of tracking who did what for the sake of management.

• ■   The system shows the display name and adds the username when required to clarify identical display names.

Tip When you take ownership of a task, you should also reestimate the remaining work. The current number might be a team estimate or the estimate from another Developer who previously worked on the task. Now that you know that you will be doing the work, you should do another estimate.

Smell It’s a smell when I see a Developer regularly having more than one in-progress task at a time. There are situations where this can occur, such as when the original task gets blocked or the work “merges” with the new task. If a task is blocked, it should be put back into the To Do column with an appropriate note or tag or put into a custom Blocked column. In general, Developers should strive to limit their work in progress—ideally to one—in order to maximize their focus and productivity.

I’m often asked by teams new to Scrum (and Azure Boards) if the Developer should be the one who physically sets ownership of their task, or if someone else—like the Scrum Master—should do it. My answer is to let the team decide. Yes, this might be a helpful practice for a new Scrum Team to adopt in order to shed any of its old command-and-control (C&C)-style behavior. If no such behavior existed, then I say let the Developer closest to the keyboard (or the one with the best keyboarding skills) get the job done. If a question, disagreement, or problem arises, remember that Azure Boards tracks who adds or changes a work item, what exactly was changed, and when.

Fabrikam Fiber Case Study

For the most part, each individual Developer manages their own tasks. Occasionally, during a Daily Scrum or other planning meeting, the Taskboard may be displayed on a large screen, with one of the Developers driving. They will create and manage the tasks at the team’s behest. Professional Scrum Teams are good about regularly rotating drivers.

Blocked Tasks

During the Sprint, tasks can become blocked. Dependencies can surface, causing progress on an existing task to be put on hold. This type of issue is normal when dealing with complex work. The question becomes how to signal to others that it has occurred. You shouldn’t simply create or pull a new task into the In Progress column without doing something with the original, blocked task.

It’s also important that the plan be updated in some way to reflect the blockage. After dragging the blocked task back to the To Do column and removing the owner’s name, you can perform any of these optional activities:

• ■   Reestimate the remaining work.

• ■   Add a note to the Description or Discussion field.

• ■   Set the Blocked field.

• ■   Tag the Task work item as Blocked.

If you mark blocked tasks by using the Blocked field or with a tag, then those work items can be styled in a way to make them more transparent on the Taskboard. Figure 6-15 shows a Blocked style rule being created to display those cards with a slight red color on the Taskboard.

FIGURE 6-15 You can style blocked tasks on the Taskboard.

As you can see, it’s very easy to style cards on the Taskboard. There really is no limit to how much bling you can apply to your cards. In addition to styling cards when they are blocked, there are some other styles that a Scrum Team may wish to consider. Styling rules also apply to the PBI work items down the left side. Table 6-1 provides some styling rule ideas, with example criteria.

TABLE 6-1 Styling rules of interest to Scrum Teams.

Rule	Example criteria
High-value PBIs	Business Value > 500
High-effort PBIs	Effort > 5
High-effort tasks	Remaining Work >8
PBI assigned to a specific area	Area Path Under Fabrikam\Mobile
PBI or Task contains specific tag	Tags Contain Blocked
Stale tasks	Changed Date @Today-3
Task assigned to a specific Developer	Assigned To = Richard
Title contains a keyword	Title Contains Foo

Another option for visualizing and managing blocked Task work items is to add a custom column to the Taskboard. You can access this feature through the Column Options link at the top of the Taskboard. I will cover this in the next section.

Customizing the Taskboard

Azure Boards allows Developers to add, rename, and remove columns on the Taskboard. For example, they could add a Blocked column to the Taskboard to hold those Task work items that are blocked—as an alternative for (or in addition to) tagging and styling those tasks.

Similar to the Kanban board, each column must map to a category state. For the Task work item type there are three category states: To Do, In Progress, and Done. At least one column must map to the To Do state and one column must map to the Done state. In other words, the In Progress column could be removed—which would be weird.

Figure 6-16 shows a Blocked column being added in-between the In Progress and Done columns and mapped to the In Progress category state. This means that blocked Task work items remain in the In Progress state when dragged to this column. I could have put this column in any location and also chosen a different category state, but this location works for most situations. The Developers can decide which mapping and column location makes the most sense for their work.

FIGURE 6-16 You can add a Blocked column to the Taskboard.

Tip The Developers may want to consider adding more than one Blocked column to the Taskboard. This way, they can differentiate between tasks that are blocked from starting from tasks that are blocked while in progress. Keep in mind that Taskboard column names must be unique.

Inspecting and Updating Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. By tracking the remaining work throughout the Sprint, the Developers can manage their progress. Professional Scrum Developers know this and regularly inspect their progress toward the Sprint Goal and how progress is trending toward completing the forecasted PBIs overall.

To help with this, Azure Boards provides an integrated, real-time Sprint burndown chart that is embedded in the Taskboard. Unfortunately, the thumbnail is too small to read and be of any use. Once you click the thumbnail, a larger, interactive burndown chart is displayed. You can open it up further in the Analytics page to gain full access to the chart’s controls, as you can see in Figure 6-17. The burndown chart visualizes the amount of remaining work within the Sprint. You can use the burndown chart to inspect progress of the work in the Sprint Backlog over the Sprint. This chart helps answer the question: Is our team on track to complete the forecasted PBIs by the end of the Sprint?

FIGURE 6-17 The burndown chart is a visual way to inspect progress.

The burndown chart provides an easy way to monitor progress during the Sprint by showing work remaining over time. Work remaining is the vertical axis and time is the horizontal axis. Remaining work is calculated as a sum of the Remaining Work (hours) field but can also be calculated as a total count of tasks remaining. The burndown can also show a count of PBIs remaining or a sum of Effort/Size points—as an alternative way to monitor progress. In addition, the burndown chart calculates and displays the average burndown rate and added scope over the course of the Sprint.

Based on historical burndown and scope increase, the burndown chart shows a projected work completion date. Using the burndown chart, the Developers can stay on top of their progress and see the immediate impact of their work against the forecasted work. The burndown chart provides the following useful metrics:

• ■   Percentage work complete   The percentage of work completed based on the original scope.

• ■   Average burndown rate   Average work completed per interval or iteration.

• ■   Total scope increase   How much work was added since the beginning of the Sprint.

• ■   Number of work items not estimated   The current number of items that do not have a value burning down on the sum of a field (Remaining Work or Effort/Size).

• ■   Projected burndown   Shows how fast the Developers are burning down the work, based on historical burndown rate.

• ■   Projected scope increase   Calculated based on historical scope increase rate.

• ■   Projected completion date   Calculated based on the Remaining Work and historical burndown and scope increase rates. If the projected completion date is before the Sprint end date, it draws a vertical line on the interval when the work should complete. If the projected completion date is beyond the Sprint end date, it displays the number of additional intervals/iterations needed to complete the work.

Note In Scrum, “projects” are always on time. This is because a project is just another name for a Sprint, and Sprints always end on time—on a specific date. Whether or not all of the expected scope (forecasted PBIs) is delivered at the end of the Sprint is the more important question.

Looking at the burndown chart, the Developers can not only get immediate insight as to their progress, but also learn about their behavior and cadence. Most burndown lines aren’t straight because Developers never move at a fixed velocity. Because of this, burndown charts also help Developers visualize the risks to their release. If the Sprint end date maps to a release date, Developers may need to reduce scope or extend the release date. Burndown charts can also indicate that progress is greater than anticipated, providing the wonderful option of collaborating with the Product Owner to add new PBIs to the Sprint.

Although the burndown is an obvious choice for inspecting progress, the Developers don’t have to use it. Progress can be assessed by direct observation of the Taskboard. Here are some approaches:

• ■   Sum work remaining   The total hours left for all To Do and In Progress tasks can be compared against the Developers’ availability for the remainder of the Sprint.

• ■   Count incomplete tasks   The total number of To Do and In Progress tasks can be compared against those that are Done as well as the Developers’ availability for the remainder of the Sprint. This approach works well when tasks are all generally the same size.

• ■   Sum PBI effort/size remaining   The total effort/size points left for all Forecasted PBIs can be compared against those that are Done as well as the Developers’ availability for the remainder of the Sprint.

• ■   Count incomplete PBIs   The total number of Forecasted PBIs can be compared against those that are Done as well as the Developers’ availability for the remainder of the Sprint. This works when PBIs are all generally the same size.

As you may have noticed, each of these approaches is available as a configuration option when viewing the burndown. If it’s easier to view the burndown, then go for it. Otherwise, just know that you can inspect progress by looking at the Taskboard itself—which Developers tend to do multiple times per day anyway.

If you want to inspect progress by counting or summing tasks, then it’s important for the Developers to regularly update the board—at least once daily. The Developers should make sure the tasks are in the correct column, are owned by the correct Developer, and contain accurate Remaining Work estimates—assuming the Developers are estimating and tracking hours by task.

Developers should inspect progress at least daily—possibly at the Daily Scrum—in order to project the likelihood of achieving the Sprint Goal. Professional Scrum Developers will update their progress several times throughout the day so that progress can be assessed more often than once daily. This means that Developers should update their Remaining Work to regularly—and honestly—reflect the time required to complete the task.

You can update the Remaining Work field quickly by clicking the number on the card and selecting a new one from the drop-down list that appears, as shown in Figure 6-18. Any change to the Remaining Work field takes place immediately. There is no need to save your changes.

FIGURE 6-18 You can set the Remaining Work field directly on the card.

Tip If the number you want is not in the drop-down list, you can just type it into the tiny field. This can be difficult on a new task where there isn’t a visible number. You will have to guess where the number would be displayed and click that area on the card. If all else fails, you can open the Task work item and change the Remaining Work field on the form.

The drop-down list provides some interesting results. The list population scheme is based on the findings of studies that Microsoft performed internally. The Azure Boards team analyzed the hour deltas as they were reduced over time so that whenever a Developer updated the Remaining Work field, they tracked the average change from the original number to the new number. After studying six months of data, they found approximately 80 percent of all deltas were within a small range of the current number. Interestingly, they also found that about 2 percent of the numbers were over 20 hours to begin with. Regardless of these findings, or how the drop-down control behaves, Developers can choose to record whatever number is accurate for them.

Note If the task has no (zero) Remaining Work, then you are presented with a Fibonacci sequence (1, 2, 3, 5, 8, 13). I think Microsoft got confused here and is suggesting standard story points rather than hours. Regardless, there might be a chance one of those numbers will work. Otherwise, you can change it to whatever you want.

Smell It’s a smell when I see a Developer tracking their actual hours worked. In complex product development, outcome is more important than output. Hopefully the members of the Scrum Team know this. The Scrum Master may have to “remind” management of this truth. Also, Scrum is a team effort, and tracking actual hours turns it into a collection of individual efforts. If management is really after the knowledge of whether the team is ahead of schedule or running behind, they could ask the Product Owner and/or inspect the Done working product at the Sprint Review. If the Developers, without any external influence, wish to track actual hours in an effort to improve their learning, that’s fine.

Fabrikam Fiber Case Study

Each Developer updates their remaining work estimates at least daily, and sometimes several times throughout the day as new tasks are worked and new assessments are made. Since the Developers tend to swarm on many PBIs, they also keep an eye on the upcoming, unassigned tasks to see if those estimates still feel right. If changes are recommended, they discuss them as needed but at least once a day at the Daily Scrum.

When all associated tasks are done, and the Definition of Done is met, the PBI is considered done. A Developer should set the PBI work item’s State to Done at that point. The Product Owner doesn’t have to be the one to flip this switch—any Developer can do it. In fact, unless it’s explicitly stated in the Definition of Done, the Product Owner has no say over whether a PBI is Done or not. After a PBI is completed, the Developers should begin swarming on the next most important item in the Sprint Backlog.

Smells

You can learn a lot about how a team is working as a team—or not working as a team—by observing the Taskboard. This, of course, assumes that the team is using the Taskboard in the way I’ve recommended in this chapter and is keeping it regularly updated—which can be challenging. I’d rather a team spend their time making the product awesome than keeping their Taskboard in good shape—but it is a balance. In addition, the observer effect can come into play. In physics the observer effect is the theory that the mere observation of a phenomenon (such as team behavior) inevitably changes that phenomenon.

As a culmination of all the guidance in this chapter, take a look at Figure 6-19 and see if you can identify the smells.

FIGURE 6-19 Can you identify the smells on this Taskboard?

Here are the smells that you should have found:

• ■   Toni has licked two cookies   There are two tasks in the To Do column with Toni’s name on it. Assuming Toni has the most experience in running tests, it’s likely that she will perform those tasks when it comes time; however, she may not be available or there might be more important work for her to help with first. Ownership should be deferred until the last responsible moment.

• ■   Missing estimates   One To Do task and two In Progress tasks are missing an estimate of remaining work. Assuming the Developers have agreed to estimate/track remaining work, this should be done consistently for all tasks in the To Do and In Progress columns. This will increase accuracy as the Developers inspect progress.

• ■   Wade must be a cyborg   Since humans are not able to multitask, how can Wade have two In Progress tasks? Perhaps he had finished one or became blocked and didn’t update the Taskboard. Perhaps he merged the work. Wade should take a moment and true-up the Taskboard.

• ■   The mysterious solution designer   The done Design Solution task has no name on it. Although the team can probably figure out who did the work, it’s best to leave the Developer’s name on it.

• ■   Why risk it?   The most serious smell—and the one that most new teams miss—is that Toni has started work on the second PBI before the first PBI was done. She would say that she is the “tester,” so therefore she does the testing tasks. Remember, in Scrum, there are no titles. Also, it’s more important that the team deliver value—by getting PBIs done—than delivering output by just doing a bunch of tasks. Toni needs to be more T-shaped.

Tip If the Developers struggle with the dysfunctional behaviors behind these smells, one or more style rules can be created to highlight those cards. I covered how to do this earlier in this chapter. More importantly, they should discuss this issue in the Sprint Retrospective and come up with some experiments to try.

Closing Out a Sprint

Ideally, when Sprint Review comes, the team has achieved the Sprint Goal, completed all forecasted PBIs according to the Definition of Done, and all tasks are in the Done column. This may or may not happen. If it does, then there will be nothing a team has to do to “close out” the Sprint—just make sure all of the States are set to Done. On the other hand, when the Sprint Backlog contains PBIs that are incomplete—whether or not they were started—there will be some extra steps in order to close out the Sprint.

Here’s a list of activities that a team should do to close out a Sprint:

• ■   Move PBIs back to the Product Backlog   Any PBI that was not finished according to the Definition of Done should be moved back to the Product Backlog. This can be done by displaying the Planning pane and dragging those PBIs back to the root iteration (for example, Fabrikam Team Backlog). State values should be changed as well.

• ■   Reestimate those PBIs   The Developers will have learned more about those items, the domain, the codebase, the tools, and so forth. This new knowledge may result in new estimates. In other words, those incomplete PBIs may decrease (or increase) in size based on what the Developers have learned during the Sprint.

• ■   Salvage the plan   Some or all of the tasks may still be relevant in a future Sprint. If so, the team can use the bulk-modify Move to iteration feature of the Sprint Backlog (not the Taskboard) to change the Sprint on those tasks so that they appear in the new Sprint Backlog and Taskboard. You can see an example of this in Figure 6-20. Salvaged tasks should not be moved until Sprint Planning of that new Sprint so that the plan can be created at the last responsible moment.

FIGURE 6-20 Use the bulk-modify feature to move incomplete tasks to a future Sprint.

Smell It’s a smell when I see a Scrum Team continually pushing incomplete work to the next Sprint. Although this might reduce waste, it also decreases agility because the Product Owner may want to do something completely different in that next Sprint. Instead, they are “held hostage” by the Developers’ need to complete incomplete work from the previous Sprint. If this is a regular occurrence, then it should be a regular topic at the Sprint Retrospective. In Chapter 8, I will explore some practices and behaviors that a team can adopt to limit the risk of having incomplete work.

Canceling a Sprint

A Sprint can be canceled before its timebox is over. A Sprint would be canceled if the Sprint Goal becomes obsolete. This might occur if the organization changes direction or if business or technology conditions change radically. In general, a Sprint should be canceled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense. Only the Product Owner has the authority to cancel the Sprint, although they may do so under influence from the stakeholders or others on the Scrum Team.

When a Sprint is canceled, any done PBIs should be reviewed. These items may still be released, if the Product Owner desires. As previously mentioned, all incomplete PBIs should be reestimated and returned to the Product Backlog. Depending on the reason for the cancellation, some PBIs may no longer be needed and can be removed from the Product Backlog.

A Sprint cancellation can be traumatic to the Scrum Team because it interrupts their cadence. Cancellations are very uncommon. In fact, in my career I’ve experienced only two.

Sprint Planning Checklist

Azure Boards has first-class support for tracking the forecasted PBIs and the plan for delivering them. Developers will plan and execute their work in different ways, and Azure Boards provides several methods to assist them. For example, the Sprint Backlog can be viewed and inspected in many ways—all in order for the Developers to manage their work and assess their progress toward the Sprint Goal.

Here is a checklist for Sprint Planning:

Scrum

• ❒   Prior to Sprint Planning, know your team’s Definition of Done, availability/capacity, past performance (velocity, throughput, etc.), and any actionable improvements identified in the previous Sprint Retrospective.

• ❒   Prior to Sprint Planning, ensure the Product Backlog is refined, in good shape, and contains some ready PBIs at the top.

• ❒   Prior to Sprint Planning, the Product Owner should have a business objective or goal in mind, which may influence (or simply become) the Sprint Goal.

Azure DevOps

• ❒   Ensure the top items in the Product Backlog are ready.

• ❒   Ensure the current Sprint has been created and selected for your team.

• ❒   Set the Iteration to the current Sprint and the State to Forecasted for those PBIs selected for the Sprint.

• ❒   Add associated Task work items to each forecasted Product Backlog Item to represent the plan for delivering it (optional).

• ❒   If the PBI was planned in an earlier Sprint, bring forward any older Task work items that could still be part of the plan. Do this by setting their Iteration field to the current Sprint.

• ❒   If representing the Definition of Done with Task work items, ensure that they are each added to each forecasted PBI as applicable.

• ❒   Ensure that all Task work items have a team-estimated Remaining Work value (optional).

• ❒   Ensure that all Task work items are unassigned.

• ❒   Ensure that any “epic” tasks (such as tasks greater than 8 hours) are decomposed into two or more smaller tasks.

• ❒   Avoid setting the Activity field in the Task work item to reinforce the team’s cross-functional, self-managing, T-shaped behaviors.

Chapter Retrospective

Here are the key concepts I covered in this chapter:

• ■   The Sprint   A timeboxed event of one month or less during which a done, usable, and releasable product is developed and delivered. The Sprint is the container for the other Scrum events.

• ■   Sprint Planning   The first event in the Sprint where the work to be performed in the Sprint is forecasted and planned.

• ■   Sprint Backlog   An artifact that contains the set of forecasted PBIs plus a plan for delivering them in order to realize the Sprint Goal.

• ■   Forecast   Those PBIs that the Developers feel that they can deliver during the Sprint given current conditions.

• ■   Plan   How the Developers will work to deliver the forecasted PBIs. The plan is typically represented using tasks but can also be represented using failing tests or other artifacts.

• ■   Sprint Goal   An objective for the Sprint that can be met through the delivery of the forecasted PBIs. Since there is no first-class support for Sprint Goals in Azure Boards, a team may want to use an extension.

• ■   Past performance   A measure of how much work the Developers have been able to historically complete per Sprint. Velocity is a common measure and is the average number of size/effort points done per Sprint. The flow-based metric of Throughput would be another past performance metric to consider.

• ■   Availability   The Developers’ available time for the Sprint. Availability is one of the inputs to Sprint Planning that influences how many PBIs are forecasted. Availability is a better word to use than capacity.

• ■   Tasks   Ideally, tasks are created early in the Sprint. It’s to be expected that additional tasks will be identified and created later in the Sprint as well.

• ■   Decomposition   Generally, tasks should be small enough to be accomplished in a day or less. Larger “epic” tasks can be created during Sprint Planning as the Developers continue to brainstorm the plan, but such tasks should be decomposed later in the Sprint.

• ■   Impediments   Issues that slow or block a team’s ability to achieve the Sprint Goal. Impediments should be removed rather than managed but may require the Scrum Master’s involvement. Create an Impediment work item as a last result.

• ■   Taskboard   The Taskboard is a great way to visualize the work in progress, as well as the work yet to be done in the Sprint. Progress can be inspected in many ways on the Taskboard.

• ■   Taking ownership of a task   Developers take ownership of Task work items by setting the Assigned To field to their username. This should only be done when that Developer begins working on the task. Work is never assigned in Scrum.

• ■   Changing the state of a task   A Developer can change the state of a task by dragging it to the respective column in the Taskboard. The board should accurately reflect the work the Developers are doing.

• ■   Updating remaining work   Each Developer should reestimate the remaining work for their tasks at least once per day. Use the Taskboard to update these values quickly.

• ■   Burndown   A chart that shows how quickly the Developers are completing tasks or PBIs. A burndown chart is a great tool for inspecting progress in order to update the plan and expectations.