Azure Boards

The Scrum Process

Shortly after Microsoft released Team Foundation Server 2010, they made the Microsoft Visual Studio Scrum version 1.0 process template available for download. This new template was designed from the ground up to embrace the rules of Scrum as defined in the Scrum Guide. It was the result of collaboration between Microsoft, Scrum.org, and the Professional Scrum community. Everyone knew that Scrum had become the dominant agile framework in software development. Microsoft recognized this as well. They also knew that teams using Team Foundation Server and Scrum together wanted a lighter-weight experience, resulting in less friction. What resulted was a minimalistic process template that followed the rules of Scrum. There were over 100,000 downloads of this new process template in the first couple of years.

Over the years, through ongoing collaboration with the Professional Scrum community, Microsoft learned a thing or two about the Scrum process and the community using it. Primarily, they have learned that teams liked it! These teams appreciate its simplicity and straightforward support of Scrum. As you saw in Table 3-1, there are not a lot of extraneous work item types beyond what is needed to plan and track a project using Scrum. In fact, it’s even more lightweight than the Agile process.

Many Scrum Teams evaluating Azure Boards currently use whiteboards and sticky notes to track their work. Since you can’t get any lighter weight than that, any prospective software tool would need to be as lightweight as possible. We kept this guiding principle in mind as we created the Scrum process, and I still keep it in mind as I write this book.

Scrum Work Item Types

I want to spend some time talking specifically about the work item types in the Scrum process, and how a Scrum Team should (and shouldn’t) use them. I will focus on just those items that directly relate to planning and executing work. The work items related to Azure Test Plans (test plans, test suites, test cases, etc.) will be covered in Chapter 7.

Product Backlog Item

In Scrum, the Product Backlog is an ordered (prioritized) list of the outstanding work necessary to realize the vision of the product. This list can contain new things that don’t exist yet (features), as well as broken things that need to be fixed (bugs). In Azure Boards, the Product Backlog Item (PBI) work item type enables the Scrum Team to capture all of these various requirements with the least amount of documentation as is necessary. In fact, only the title field is required.

Later, as more detail emerges, the PBI can be updated to include business value, acceptance criteria, and an estimation of effort, as you can see in Figure 3-3.

As you create or edit PBI work items, consider the following Professional Scrum guidance while entering data in the pertinent fields:

• Title (Required)   Enter a short description that succinctly identifies the PBI.

• Assigned To   Select the Product Owner or leave blank, but don’t assign to a Developer. This will reinforce the fact that the whole team owns the work on the PBI.

• Tags   Optionally add tag(s) to help find, filter, and identify the PBI. For example, some Scrum Teams opt not to use the Bug work item type in lieu of the PBI work item type and will simply tag those PBIs with “Bug.”

• State   Select the appropriate state of the PBI. States are covered later in this section.

• Area   Select the best area path for the PBI. Areas must be set up ahead of time and can represent functional, logical, or physical areas or features of the product. If the PBI applies to all areas your team covers or you aren’t sure of the specific area, then leave it set to its default value. For Nexus implementations, each team within a project can have its own corresponding areas as well as a default area. I will talk about Nexus in Chapter 11, “Scaled Professional Scrum.”

• Iteration   Select the Sprint in which the Developers forecast that they will develop the PBI. If they have yet to forecast the PBI, then leave it set to the default (root) value.

• Description   Provide as much detail as necessary so that another team member or stakeholder can understand the purpose of the PBI. The user story format (As a <type of user>, I want <some goal>, so that <some reason>) works well here to ensure that the who, what, and why are captured. You should avoid using this field as a repository for detailed requirements, specifications, or designs.

• Acceptance Criteria   Describe the conditions that will be used to verify whether the team has developed the PBI according to expectations. Acceptance criteria should be clear, concise, and testable. You should avoid using this field as a repository for detailed requirements. Bulleted items work well. Gherkin (given-when-then) expressions work even better.

• Discussion   Add or curate rich text comments relating to the PBI. You can mention someone, a group, a work item, or a pull request as you add a comment. Professional Scrum Teams prefer higher-fidelity, in-person communication instead.

• Effort   Enter a number that indicates a relative rating (size) of the amount of work that will be required to develop the PBI. Larger numbers indicate more effort than smaller numbers. Fibonacci numbers (story points) work well here. T-shirt sizes (S, M, L, XL) don’t, only because this is a numeric field. Effort can be considered the (I)nvestment in Return on Investment (ROI).

• Business Value   Enter a number that indicates a fixed or relative value of delivering the PBI. Larger numbers indicate more value than smaller numbers. Fibonacci numbers work well here. Business Value can be considered the (R)eturn in ROI.

• Links   Add a link to one or more work items or resources (build artifacts, code branches, commits, pull requests, tags, GitHub commits, GitHub issues, GitHub pull requests, test artifacts, wiki pages, hyperlinks, documents, and version-controlled items). You can see an example of linking a PBI to a wiki page in Figure 3-4. You should avoid explicitly linking PBIs to other PBIs, features, or epics using the Links tab. Instead, use drag and drop to establish hierarchical relationships within the backlogs. I will cover this in Chapter 5, “The Product Backlog.”

  

  FIGURE 3-4 Adding a link to a wiki page.

• Attachments   Attach one or more files that provide more details about the PBI. Some teams like to attach notes, whiteboard photos, or even audio/video recordings of the Product Backlog refinement sessions and Sprint Planning meetings.

• History   Every time a team member updates the work item, Azure Boards tracks the team member who made the change and the fields that were changed. This tab displays a history of all those changes. The contents are read-only.

While the PBI progresses on its journey to “ready” for Sprint Planning, the previous list of fields are really the only ones that need to be considered and completed. For the other fields on the PBI work item form, you should discuss as a team whether or not you should be using them because tracking data in those fields is most likely waste. When the PBI is forecast to be developed, additional fields and links will start to emerge, including links to task and test case work items, test results, commits, and builds.

A PBI work item can be in one of five states: New, Approved, Committed, Done, or Removed. The typical workflow progression would be New ⇒ Approved ⇒ Committed ⇒ Done. When a PBI is created, it is in the New state. When the Product Owner decides that the PBI is valid, its state should change from New to Approved. When the Developers forecast to develop the PBI in the current Sprint, its state should change to Committed. Finally, when the PBI is done, according to the Definition of Done, the state should change to Done. The Removed state is used for situations where the Product Owner determines that the PBI is invalid for whatever reason, such as it is already in the Product Backlog, has already been developed, has gone stale, or is an utterly ridiculous idea. Deleting the work item is another option for these situations.

Bug

A bug communicates that a problem or potential problem exists in the product. A bug can be found in a product that has already been delivered to production, in a done Increment from a previous Sprint, or in the Increment being developed in the current Sprint. A bug is not—repeat not—a failed test. Failed tests simply indicate that the team is not yet done. This will be covered more in Chapter 7.

By defining and managing Bug work items, the Scrum Team can track these problems, as well as prioritize and plan the efforts to fix them. A bug could be as small as a typo in a data entry form or as large as a vulnerability that allows credit card data to be exposed. Figure 3-5 shows a Bug work item.

When you create a Bug work item, you want to accurately report the problem in a way that helps the reader understand its full impact. The steps to reproduce the bug should also be listed so that other Developers can reproduce the behavior. There may be additional analysis (triage) required to confirm that it is an actual bug rather than a behavior that was by design. By defining and managing Bug work items, your team can track defects in the product in order to estimate and prioritize their resolution. As a general rule, bugs should be removed, not managed.

As you create or edit Bug work items, consider the following Professional Scrum guidance while entering data into the pertinent fields:

• Title (Required)   Enter a short description that succinctly identifies the bug.

• Assigned To   Select the Product Owner or leave blank, but don’t assign to anyone else. This will reinforce the fact that the whole team owns the work on the bug.

• Tags   Optionally add tag(s) to help find, filter, and identify the bug.

• State   Select the appropriate state of the bug. States are covered later in this section.

• Area   Select the best area path for the bug. Areas must be set up ahead of time and can represent functional, logical, or physical areas or features of the product. If the bug applies to all areas your team covers or you aren’t sure of the specific area, then leave it set to its default value. For Nexus implementations, each team within a project can have its own corresponding areas as well as a default area.

• Iteration   Select the Sprint in which the Developers forecast that they will fix the bug. If they have yet to forecast the bug, then leave it set to the default (root) value.

• Repro Steps   Provide as much detail as necessary so that another team member can reproduce the bug and better understand the problem that must be fixed. If you use the Test & Feedback extension to create a Bug work item, this information is provided automatically from your test session.

• System Info   Describe the environment in which the bug was found. If you use the Test & Feedback extension to create the Bug work item, this information is provided automatically from your test session.

• Acceptance Criteria   Describe the conditions that will be used to verify whether the team has fixed the bug according to expectations. Acceptance criteria should be clear, concise, and testable. Consider using this field to document the expected results, as opposed to the actual results.

• Discussion   Add or curate rich text comments relating to the bug. You can mention someone, a group, a work item, or a pull request as you add a comment. Professional Scrum Teams prefer higher-fidelity, in-person communication instead.

• Severity   Since the Bug work item type doesn’t have a Business Value field, you will need to instead select the value that indicates the impact that the bug has on the product or stakeholders. The range is from 1 (critical) to 4 (low). Lower values indicate a higher severity. The default severity is 3 (medium).

• Effort   Enter a number that indicates a relative rating (size) of the amount of work that will be required to fix the bug. Larger numbers indicate more effort than smaller numbers. Fibonacci numbers (story points) work well here. T-shirt sizes don’t, only because this is a numeric field. Effort can be considered the (I)nvestment in ROI.

• Found In Build   Optionally select the build in which the defect was found.

• Integrated In Build   Optionally, select a build that incorporates the bug fix.

• Links   Add a link to one or more work items or resources (build artifacts, code branches, commits, pull requests, tags, GitHub commits, GitHub issues, GitHub pull requests, test artifacts, wiki pages, hyperlinks, documents, and version-controlled items). You can link the bug to a related bug, to an article explaining the root cause, to the original PBI that failed, or even to a parent PBI that serves to gather several bugs into one collective “fix” user story.

• Attachments   Attach one or more files that provide more details about the bug. Some teams like to attach notes, whiteboard photos, or even audio/video recordings. This could also include screenshots, action recordings, and video, which the Test & Feedback extension can provide automatically.

• History   Every time a team member updates the work item, Azure Boards tracks the team member who made the change and the fields that were changed. This tab displays a history of all those changes. The contents are read-only.

Just like a PBI, a Bug work item progresses on its journey to “ready” for Sprint Planning, the previous list of fields are really the only ones that need to be considered and completed. If there are other fields on your Bug work item form, you should discuss as a team whether or not you should be using them because tracking data in those fields is most likely waste. When the bug is forecasted to be fixed, additional fields and links will start to emerge, including links to task and test case work items, test results, commits, and builds.

A Bug work item, like the PBI work item, can be in one of five states: New, Approved, Committed, Done, or Removed. The typical workflow progression would be New ⇒ Approved ⇒ Committed ⇒ Done. When a bug is reported and determined to be genuine (that is, it’s not a feature, a duplicate, or a training issue), a new Bug work item is created in the New state. When the Product Owner decides that the bug is valid, its state should change from New to Approved. When the Developers forecast to fix the bug in the current Sprint, its state should change to Committed. Finally, when the bug is done, according to the Definition of Done, the state should change to Done. The Removed state is used for situations where the Product Owner determines that the bug is invalid for whatever reason, such as it’s already in the Product Backlog, it’s actually a feature, it’s a training issue, it’s not worth the effort, or it has already been fixed. Deleting the work item is another option for these situations.

Epic

In Scrum, there is only one Product Backlog for a product and it contains only Product Backlog items. Some PBIs are quite small, deliverable in a single Sprint or less. Other PBIs are larger and may take more than one Sprint to complete. Huger PBIs may take many Sprints, even up to a year or more to complete. In Scrum, regardless of size, each item is simply called a Product Backlog item.

Organizations and teams prefer to have more specific language. They also prefer to have separate backlogs for these different-sized items, and that’s why Azure Boards provides hierarchical backlogs. With hierarchical backlogs, an organization or team can start with “big picture” ideas called epics and break them down into more releasable-sized items called features, and finally into smaller, more executable-sized items.

An epic represents a business initiative to be accomplished, like these examples:

• Increase customer engagement

• Improve and simplify the user experience

• Implement microservices architecture to improve agility

• Integrate with SAP

• Native iPhone app

Epic work items are similar to PBI work items. As you create or edit Epic work items, consider the following Professional Scrum guidance while entering data into the pertinent fields:

• Title (Required)   Enter a short description that succinctly identifies the epic.

• Assigned To   Select the Product Owner or leave blank. Alternatively, you can assign it to the stakeholder advocating for the epic.

• Tags   Optionally add tag(s) to help find, filter, and identify the epic.

• State   Select the appropriate state of the epic. States are covered later in this section.

• Area   Select the best area path for the epic. Areas must be set up ahead of time and can represent functional, logical, or physical areas or features of the product. If the area applies to all areas your team covers or you aren’t sure of the specific area, then leave it set to its default value. For Nexus implementations, each team within a project can have its own corresponding areas as well as a default area.

• Iteration   Optional, but you can select the Sprint in which the Developers forecast that they will either begin or complete the development of the epic. If they have yet to begin work, then leave it set to the default (root) value.

• Description   Provide as much detail as necessary so that another team member or stakeholder can understand the purpose and goal of the epic.

• Acceptance Criteria   Describe the conditions that will be used to verify whether the team has developed the epic according to expectations.

• Discussion   Add or curate rich text comments relating to the epic. You can mention someone, a group, a work item, or a pull request as you add a comment. Professional Scrum Teams prefer higher-fidelity, in-person communication instead.

• Start Date   Optional, but you can set the date that work will commence on the epic. This could be the start date of the Sprint when the first PBI related to the epic is forecast for development. This field is key to using Delivery Plans.

• Target Date   Optional, but you can set the date that the epic should be implemented. This field is key to using Delivery Plans.

• Effort   Enter a number that indicates a relative rating (size) of the amount of work that will be required to develop the epic. Larger numbers indicate more effort than smaller numbers. Fibonacci numbers (story points) work well here. T-shirt sizes don’t, only because this is a numeric field. Effort can be considered the (I)nvestment in ROI.

• Business Value   Enter a number that indicates a fixed or relative value of delivering the epic. Larger numbers indicate more value than smaller numbers. Fibonacci numbers work well here. Business Value can be considered the (R)eturn in ROI.

• Links   Add a link to one or more work items or resources (build artifacts, code branches, commits, pull requests, tags, GitHub commits, GitHub issues, GitHub pull requests, test artifacts, wiki pages, hyperlinks, documents, and version-controlled items). You should avoid explicitly linking epics to other epics, features, or PBIs using the Links tab. Instead, use drag and drop to establish hierarchical relationships on the backlog using the Mapping pane.

• Attachments   Attach one or more files that provide more details about the epic. Some teams like to attach notes, whiteboard photos, or even audio/video recordings.

• History   Every time a team member updates the work item, Azure Boards tracks the team member who made the change and the fields that were changed. This tab displays a history of all those changes. The contents are read-only.

Epic work items can be in one of four states: New, In-Progress, Done, or Removed. The typical workflow progression would be New ⇒ In-Progress ⇒ Done. When an epic is created it is in the New state. Once work begins, you should move it to the In Progress state, as I’m doing in Figure 3-7. Finally, when the epic is finished, because the last related feature is complete, then the state should change to Done. The Removed state is used for situations where the Product Owner determines that the epic is no longer needed, for whatever reason. Deleting the work item is another option in this situation.

Refining an epic means to break it down, or decompose, into one or more features. Feature work items are then created and linked back to the parent epic. This can be done manually by using the links in the work item form; inline on the Epics backlog; or by using the Mapping feature, as I’m doing in Figure 3-8. Refining is an ongoing process, with the features changing, merging, and splitting again as the Scrum Team learns more about the domain, the product, and the stakeholders.

Feature

Whether or not you plan on using Epic work items, your team may still want to track features. Features are typically what stakeholders request and also what they expect to be delivered. If a feature is larger than can be delivered in a Sprint, then it must be broken down further—into other features or into more executable-sized items that are tracked and managed at the backlog level. Most teams I work with refer to these lowest, leaf-level items as user stories, or simply stories.

A feature typically represents a releasable component of software, like these examples:

• View technician details on the dashboard

• Ability to reassign tickets

• Support text alerts

• Find and filter tickets

Feature work items are similar to Epic work items, as you can see in Figure 3-9. As you create or edit Feature work items, consider the following Professional Scrum guidance while entering data into the pertinent fields:

• Title (Required)   Enter a short description that succinctly identifies the feature.

• Assigned To   Select the Product Owner or leave blank, but don’t assign to anyone else. This will reinforce the fact that the whole team owns the work on the feature.

• Tags   Optionally add tag(s) to help find, filter, and identify the feature.

• State   Select the appropriate state of the feature. States are covered later in this section.

• Area   Select the best area path for the feature. Areas must be set up ahead of time and can represent functional, logical, or physical areas or features of the product. If the area applies to all areas your team covers or you aren’t sure of the specific area, then leave it set to its default value. For Nexus implementations, each team within a project can have its own corresponding areas as well as a default area.

• Iteration   Optional, but you can select the Sprint in which the Developers forecast that it will either begin or complete the development of the feature. If they have yet to begin work, then leave it set to the default (root) value.

• Description   Provide as much detail as necessary so that another team member or stakeholder can understand the purpose and goal of the feature.

• Acceptance Criteria   Describe the conditions that will be used to verify whether the team has developed the feature according to expectations.

• Discussion   Add or curate rich text comments relating to the feature. You can mention someone, a group, a work item, or a pull request as you add a comment. Professional Scrum Teams prefer higher-fidelity, in-person communication instead.

• Start Date   Optional, but you can set the date that work will commence on the feature. This could be the start date of the Sprint when the first PBI related to the feature is forecasted for development. If using epics, then the epic’s start date might coincide with the first related feature’s start date. This field is key to using Delivery Plans.

• Target Date   Optional, but you can set the date that the feature should be implemented. If using epics, then the epic’s target date might coincide with the last related feature’s start date. This field is key to using Delivery Plans.

• Effort   Enter a number that indicates a relative rating (size) of the amount of work that will be required to develop the feature. Larger numbers indicate more effort than smaller numbers. Fibonacci numbers (story points) work well here. T-shirt sizes don’t, only because this is a numeric field. Effort can be considered the (I)nvestment in ROI.

• Business Value   Enter a number that indicates a fixed or relative value of delivering the feature. Larger numbers indicate more value than smaller numbers. Fibonacci numbers work well here. Business Value can be considered the (R)eturn in ROI.

• Links   Add a link to one or more work items or resources (build artifacts, code branches, commits, pull requests, tags, GitHub commits, GitHub issues, GitHub pull requests, test artifacts, wiki pages, hyperlinks, documents, and version-controlled items). You should avoid explicitly linking features to other features, epics, or PBIs using the Links tab. Instead, use drag and drop to establish hierarchical relationships on the backlog using the Mapping pane.

• Attachments   Attach one or more files that provide more details about the feature. Some teams like to attach notes, whiteboard photos, or even audio/video recordings.

• History   Every time a team member updates the work item, Azure Boards tracks the team member who made the change and the fields that were changed. This tab displays a history of all those changes. The contents are read-only.

Feature work items can be in one of four states: New, In-Progress, Done, or Removed. The typical workflow progression would be New ⇒ In-Progress ⇒ Done. When a feature is created it is in the New state. Once work begins, you should move it to the In-Progress state. Finally, when the feature is finished, because the last related PBI is complete, then the state should change to Done. The Removed state is used for situations where the Product Owner determines that the feature is no longer needed, for whatever reason. Deleting the work item is another option in this situation.

Refining a feature means to break it down, or decompose, into one or more PBI work items. PBI work items are then created and linked back to the parent feature. This can be done manually by using the links in the work item form; inline on the Features backlog; or by using the Mapping feature, as I’m doing in Figure 3-10. Refining is an ongoing process, with the PBIs changing, merging, and possibly splitting again as the Scrum Team learns more about the domain, the product, and the stakeholders.

Task

A Task work item represents a piece of detailed work that Developers must accomplish when developing a PBI. All tasks form the Sprint plan for achieving the Sprint Goal. These tasks, along with their associated PBIs, constitute the Sprint Backlog.

A task can be analysis, design, development, testing, documentation, deployment, or operations in nature. For example, the team can identify and create Task work items that are development focused, such as implementing an interface or creating a database table. They can also create testing-focused tasks, such as creating a test plan and running tests. A deployment-focused task might be to provision a set of virtual machines for hosting the deployed application. Figure 3-12 shows an example Task work item.

As you create or edit Task work items, consider the following Professional Scrum guidance while entering data in the pertinent fields:

• Title (Required)   Enter a short description that provides a concise overview of the task. The title should be short but descriptive enough to allow the team to quickly understand what work is to be performed. Some teams have adopted a simple verb-noun naming convention (e.g., Create tests, Write code, Deploy app, etc.).

• Assigned To   Select the team member who is responsible for ensuring that the task is completed. A task can be assigned to only one person at a time, so if two people pair up on a task, or the team mobs on a task, just pick one of them to be the owner. Leave it blank until someone starts working on it.

• Tags   Optionally add tag(s) to help find and identify the task.

• State   Select the appropriate state of the task. States are covered later in this section.

• Area   (optional) Typically matches the associated PBI that you are working on. When tasks are created from the Taskboard, the Area is automatically populated with the parent PBI’s area.

• Iteration   Select the Sprint in which your team will be working on the task. The Sprint should be the same as the associated PBI. When tasks are created from the Taskboard, the Iteration is automatically populated.

• Description   (optional) Provide as much detail as is necessary so that another team member can understand the nature of work to be performed in the task. A meaningful title might be sufficient. Some teams like to track task-level acceptance criteria for particularly complex tasks in this field. Avoid using this field as a repository for detailed requirements, specifications, or designs.

• Discussion   Add or curate rich text comments relating to the task. You can mention someone, a group, a work item, or a pull request as you add a comment. Professional Scrum Teams prefer higher-fidelity, in-person communication instead.

• Remaining Work   The estimated hours of work remaining to complete the task.

• Blocked   (optional) Indicates whether the task is blocked from being accomplished. Blocked work should be identified and mitigated immediately. Instead of using the Blocked field, some teams have opted to use a “Blocked” tag.

• Links   Add a link to one or more work items or resources (build artifacts, code branches, commits, pull requests, tags, GitHub commits, GitHub issues, GitHub pull requests, test artifacts, wiki pages, hyperlinks, documents, and version-controlled items). In general, you should avoid manually linking tasks to other PBIs, preferring to use the Sprint Backlog or Taskboard instead. Linking tasks to other tasks can help visualize dependencies, but it also has the smell of a command-and-control work breakdown structure.

• Attachments   Attach one or more files that provide more details about the task. Some teams like to attach notes, whiteboard photos, or even audio/video recordings.

• History   Every time a team member updates the work item, Azure Boards tracks the team member who made the change and the fields that were changed. This tab displays a history of all those changes. The contents are read-only.

As your team uses tasks to plan, visualize, and manage its Sprint work, the previous list contains the only fields that you need to consider and complete. If there are other fields on your Task work item form, such as Priority or Activity, you should discuss as a team whether or not you should be using them because tracking data in those fields is most likely waste. That said, at the end of the day, how the team works, which includes how they will use Azure Boards, is up to them—which is an example of self-management.

A Task work item can be in one of four states: To Do, In Progress, Done, or Removed. The typical workflow progression would be To Do ⇒ In Progress ⇒ Done. When a task is created, it is in the To Do state. When a team member begins working on a task, the state should be set to In Progress. When the task is finished, the state should be set to Done. The Removed state is used for situations where the Developers determine that the task is invalid for whatever reason, such as it doesn’t apply anymore or it was a duplicate. Deleting the work item is another option for these situations.

Impediment

An Impediment work item is a report of any situation that blocks the team or a team member from completing work efficiently. By defining and managing Impediment work items, a Scrum Team can identify and track problems that are blocking it. More importantly, they’ll have a backlog from which to work on improvements.

Impediments can be identified and, optionally recorded, at any time. They should be made transparent at least once a day, perhaps during the Daily Scrum. Professional Scrum Teams, however, don’t wait until the Daily Scrum to raise and/or fix impediments. If the impediment is something that can be removed immediately, that’s what should be done. If not, then the impediment could be recorded as an Impediment work item. The Scrum Team may also record impediments on a physical board or on a wiki page. Regardless, it’s better to remove impediments than to track and manage them. The Scrum Master is responsible for facilitating the resolution of impediments—that the team cannot resolve themselves—as well as improving team productivity.

Figure 3-13 shows you an example of an Impediment work item.

As you create or edit Impediment work items, consider the following Professional Scrum guidance while entering data in the pertinent fields:

• Title (Required)   Enter a short description that accurately and succinctly describes the impediment.

• Assigned To   Select the team member or stakeholder who will be responsible for resolving the impediment. Don’t assume that the Scrum Master will always own/remove impediments.

• Tags   Optionally add tag(s) to help find and identify the impediment.

• State   Select the appropriate state of the impediment. States are covered later in this section.

• Area   (optional) Select the best area for the impediment. If the impediment applies to all areas your team covers or you aren’t sure of the specific area, then leave it set to its default value.

• Iteration   (optional) Typically a team selects the Sprint in which the impediment occurred, but Iteration could also represent the Sprint in which the impediment was removed. Leaving it set to its default value is fine as well.

• Description   Provide as much detail as necessary so that another person can understand the impediment and its impact.

• Resolution   Provide as much detail as necessary to describe how the impediment was resolved. Over time, these resolutions could establish a “lessons learned” reference.

• Discussion   Add or curate rich text comments relating to the impediment. You can mention someone, a group, a work item, or a pull request as you add a comment. Professional Scrum Teams prefer higher-fidelity, in-person communication instead.

• Priority   Select the level of importance for the impediment on a scale of 1 (most important) to 4 (least important). The default value is 2.

• Links   Add a link to one or more work items or resources (build artifacts, code branches, commits, pull requests, tags, GitHub commits, GitHub issues, GitHub pull requests, test artifacts, wiki pages, hyperlinks, documents, and version-controlled items). For example, you may want to link the impediment to one or more blocked tasks or PBIs or other impediments.

• Attachments   Attach one or more files that provide more details about the impediment. Some teams like to attach notes, whiteboard photos, or even audio/video recordings.

• History   Every time a team member updates the work item, Azure Boards tracks the team member who made the change and the fields that were changed. This tab displays a history of all those changes. The contents are read-only.

An Impediment work item can be either Open or Closed. When an impediment is created, it is in the Open state. When the impediment is resolved/removed, the state should be set to Closed. Deleting the impediment after it has been removed is another option.

Impediments can be configured to show on the Boards. You can also track and manage them using a work item query. A team administrator could create a shared query looking for Work Item Type of Impediment and State of Open sorted by Priority. This query could then be surfaced on a dashboard or a wiki page, as I’ve done in Figure 3-14.

Scrum Work Item Queries

Work item queries allow you to view, understand, and manage your workload. By running the appropriate query, you can return lists of work items showing you the PBIs, bugs, tasks, impediments, test cases, and other work items that pertain to you or your team. You can filter and sort those items in many ways. You can then decide on which of these work items to take action. Queries can also be used to perform bulk work item updates. For example, the Product Owner can query those PBIs in a specific area in order to make bulk changes to the Business Value field.

With queries, you can perform these functions:

• Review work that’s planned, in progress, or recently done

• Perform bulk updates, such as assigning new PBIs to the Product Owner

• Create a chart to get a count of items or the sum of a field

• Create a chart and add it to a dashboard

• View a tree of parent-child-related work items

When saving a query, you can save it to My Queries or, if you have permissions, save it to Shared Queries. As you might guess, only you can view and run queries saved under My Queries. Queries that you and others save under Shared Queries can be viewed by everyone with access to the project. Queries can be organized within folders and even marked as favorites.

Here are some queries that your Professional Scrum Team may want to create:

• Open impediments   The Scrum Team and especially the Scrum Master should be mindful of these.

• PBIs assigned to someone other than the Product Owner   In Scrum, the Product Owner, not anyone else, “owns” the Product Backlog items. Empty assigned-to values are okay.

• New or approved PBIs with tasks   It is wasteful to create tasks ahead of Sprint Planning.

• Approved PBIs without acceptance criteria   How will the team members know what the expectations are or when development is done?

• New or approved PBIs with a root-level area   Are these items really cross-cutting, or did someone just forget to assign an area?

• New or approved PBIs assigned to a Sprint   Either someone entered the wrong iteration or someone forgot to set the state.

• Committed or done PBIs without a Sprint   Either someone forgot to set the iteration or someone goofed up the state.

• PBIs without links to features   Assuming you are using features, it may be useful to see the unparented items.

• Features without links to epics   Assuming you are using epics and features, it may be useful to see the unparented items.

• Features without links to PBIs   Assuming you are using features, it may be useful to see the items without children.

• Epics without links to features   Assuming you are using epics and features, it may be useful to see the items without children.

Here are some additional query ideas that pertain to the current Sprint:

• Committed PBIs without tasks   Perhaps the plan for delivering these items really is that simple. It’s more likely that the team forgot to create a plan or a PBI was snuck into the Sprint after Sprint Planning.

• Committed PBIs with associated tasks from other Sprints   These PBIs were either rolled over from a previous Sprint with a part of the plan remaining in that Sprint, or there are some serious problems with your iteration values or planning practices.

• Committed or done PBIs with no business value   How will the Product Owner explain the investment in something with no value? More likely, someone forgot to enter the business value.

• Committed or done PBIs with no effort   Well, that was easy. Somebody probably forgot to enter the effort.

• Committed or done PBIs without acceptance criteria   How will the team members know what the expectations are or when development is done?

• To-do or in-progress tasks outside of current Sprint   Looks like a previous Sprint plan was not cleaned up correctly.

• To-do tasks are assigned to a team member   It’s better to leave to-do tasks unassigned so that any team member with capacity can help out in order to increase the chances of meeting the Sprint Goal.

• To-do or in-progress tasks without remaining work   Assuming your team has a working agreement to estimate hours for tasks, this query can show those tasks that were overlooked.

• To-do or in-progress tasks with remaining work > 8   Assuming your team has a working agreement that no task should take longer than 8 hours, this query can show those tasks that need to be decomposed.

• Tasks not linked to a PBI   Not all work in the Sprint Backlog needs to pertain to developing the forecasted PBIs, but it can be a smell if there are “free-floating” tasks in there.

• Tasks with activity set   Assuming you follow my advice in this chapter and don’t see any value in using this field, then it can be helpful to see which tasks may have this accidentally set. You can then turn this into a learning opportunity.

• Blocked tasks   Whether the Scrum Team uses the Blocked field or sets a tag or both, it can be useful to know which tasks are currently blocked.

• In-progress tasks not assigned to a team member   Who’s working on these tasks?

• One team member has multiple in-progress tasks   Don’t you know that multitasking is a myth and attempting it will damage your brain? Perhaps one of the tasks is actually done or blocked.

• Team members without tasks   With the exception of the Product Owner and Scrum Master (unless they are also a Developer), everyone should be working out of the Sprint Backlog. Be careful with this query—it could become a weapon in the wrong hands.

• Done tasks have remaining work > 0   How can you be done with a task if there is still remaining work? More than likely, this was just an oversight.

• Done PBI has new or in-progress tasks   How can you be done with a PBI if one or more associated tasks are not done?

If the Scrum Team is using Azure Test Plans, there are a few more query ideas to consider, specifically related to testing:

• New or approved PBIs with test cases   It is wasteful to create test cases ahead of Sprint Planning.

• Committed PBIs without test cases   Perhaps you are proving acceptance in some other way, such as exploratory testing.

• No test plan for current Sprint   Maybe this Sprint is exceptional and doesn’t require any acceptance testing, or more likely, someone hasn’t created a test plan for it yet.

• Test cases not linked to a PBI   It’s a smell to see test cases in a test plan that are not explicitly linked to one or more PBIs. Perhaps it is a cross-cutting acceptance test, but it could also be an oversight.

Scrum Guide Drift

When the Scrum process (formerly known as the Visual Studio Scrum process template) was introduced at Microsoft’s TechEd North America conference in New Orleans in 2010, it exactly matched the Scrum Guide. Over the years, however, the two have drifted apart. The Scrum Guide evolved while the Scrum process template did not. For example, in late 2014 Microsoft went crazy and added support for the Scaled Agile Framework (SAFe) to all of their process templates—even our beloved Scrum one. Although this was good in that users now had additional hierarchy support in the backlog, it also added extraneous fields.

Also, in 2014 the Scrum Guide was moved off Scrum.org and posted to the neutral ScrumGuides.org. At the same time, all the major Scrum organizations in the world acknowledged this as the official definition of Scrum. Unfortunately, Microsoft didn’t get the memo. Sure, they still have a Scrum process, but it no longer matched the Scrum Guide and it was no longer “barely sufficient.”

Over the years the Professional Scrum community has maintained in close relationship with Microsoft, and we’ve done what we could to keep the Scrum process from drifting too far from the Scrum Guide. In this section, I will explore the current differences between the two.

Work Item Types

Azure DevOps offers more than a dozen work item types—most of which don’t particularly relate to planning and managing work. Therefore, I will focus only on those work item types that I have previously listed in the Scrum process section.

• Bug   The Scrum Guide does not mention bugs at all. That’s because a bug is a type of PBI. The confusing part is that the Scrum process also includes a PBI work item type. In my opinion, the only reason the Bug work item type exists is so that tooling such as the Test & Feedback extension can create a specific work item with repro steps and system information—both of which could be tracked in a PBI work item’s description field.

• Epic and Feature   Again, the Scrum Guide only mentions Product Backlog items. It doesn’t mention epics and it doesn’t mention features. Microsoft did this back in 2014 to support SAFe. Professional Scrum Teams using Azure Boards have since become comfortable with hierarchical backlogs, even though they could have engineered these backlogs to use the existing PBI work item type on all backlog levels.

Backlog Levels

As I have mentioned, Microsoft introduced hierarchical backlogs to support scaled agile practices. If they had kept the PBI work item type at each backlog level, that would have kept in alignment with Scrum. But since they didn’t, we now have epics, features, and PBI work item types, and the result is a goofy mix of terminology.

If organizations and teams want to use the hierarchical backlogs, and most of the ones I consult with do, then perhaps Microsoft could rename the lowest leaf-level “Backlog items” to something like “Stories”—which is the most popular term I see used. In this way, it’s made clearer that the names of the backlog levels are all not Scrum but more industry-standard names for types of PBIs. You and your organization can refer to the items in this lowest level however you’d like.

PBI Work Item Fields

Over the years, Microsoft has added many fields to the “barely sufficient” PBI work item type. In this section, I will take a look at those fields in the PBI work item type and give my Professional Scrum opinions, including why the use of some may be considered waste.

• Assigned To   Sounds very command-and-control. The label and underlying field should be changed to something that sounds more like a tool for self-managing teams, such as Owned By. Also, Azure DevOps should let you tag which user in the project is the “Product Owner” and make that the default value of this field.

• Reason   For the Scrum process, the reasons are all read-only and weak. This field should just be removed or hidden from the form.

• Iteration   Should always default to the root level when adding a PBI. Rarely would a Scrum Team add a PBI directly to an existing Sprint. Microsoft got carried away with the use of a team’s default iteration in this regard.

• Priority   Product Owners don’t necessarily need a field for priority, as the position of the PBI in the ordered Product Backlog suggests its “priority.” If a Product Owner wants to track an individual PBI’s priority, it would be better to express business priority using the Business Value field so that all PBIs can be compared relative to each other on a common field and using a common scale like Fibonacci.

• Effort   Invokes thoughts of specifying hours and classic project management, instead of something more abstract and better suited for complex work like Fibonacci numbers or story points. Size would be a better label and underlying field name.

• Value area   Product Backlog items can have value for a number of reasons, well beyond the two options in this drop-down. What’s more, teams may think that architecture work has value, which is rarely the case. Architectural work is required to deliver the kind of value that a stakeholder is looking for, but it’s rarely of direct value itself. It’s better to not use this field so that all items can have a measure of value relative across the same stratification.

• Business Value   As a corollary to what I mentioned earlier, I think Value would be a much simpler and better label and underlying field name.

PBI Work Item Workflow States

One of the most controversial updates to the 2011 Scrum Guide was the removal of the term “commit” in favor of “forecast” in regard to the work selected for a Sprint. Prior to this change, practitioners used to say that the Development Team commits to the Product Backlog Items that it will deliver by the end of the Sprint. Scrum now calls that selection and practice a forecast—because it better reflects the reality of doing complex work in a complex domain.

Well, as you can guess, Microsoft never updated the Scrum process. The Scrum community has had to put up with the Committed workflow state, as you can see in Figure 3-15. I would welcome the change to Forecasted, or even Planned.

Another small nit I have with the workflow states is the state of Approved. It’s not bad, but Ready would be preferred. Although “Ready” is not an official thing in Scrum, it is mentioned in older Scrum Guides: “Product Backlog items that can be ‘Done’ by the Development Team within one Sprint are deemed ‘Ready’ for selection in a Sprint Planning.”