Chapter 4
The Pre-game
In the game of rugby, or any professional sport for that matter, many activities must be performed prior to kickoff: prior games are analyzed, sponsors are secured, stakeholder input is provided, rules get clarified, playing fields get selected, calendar dates get negotiated, teams get selected, and player positions get designated. Scrum development efforts also have a pre-game, where many of these same types of activities are performed. The Scrum pre-game is the time period when the vision is established all the way up to the start of the first Sprint. The pre-game is not timeboxed, and not all development efforts make it out of the pre-game.
Many important activities can be performed during the pre-game (in no particular order):
■ Establish the vision, scope, and goals of the product.
■ Identify sponsors and stakeholders.
■ Establish the Scrum Team (Product Owner, Scrum Master, and Developers).
■ Establish the software development environment (e.g., provision Azure DevOps, build and release pipeline agents, deployment environments).
■ Educate individuals on the rules of Scrum.
■ Educate individuals on Azure DevOps.
■ Define the high-level product requirements.
■ Create the initial Product Backlog.
I recognize that some of the activities I outline in this chapter are considered to be execution in nature as opposed to preparation. An example of an execution activity would be provisioning Azure DevOps. Some Scrum Teams prefer to do these kinds of activities during an actual Sprint, within a timebox and while collaborating with an engaged Product Owner. Since many of the activities I outline in this chapter are executed one time only and must be performed before development using Azure DevOps can occur, I have lumped them together into the pre-game.
Smell It’s a smell when I see a team spending too much time setting up their environment. Developers do not need the most perfectly awesome configuration of tools prior to their first Sprint. In fact, not until they begin work will they actually know what they need. Just as their software product will evolve, so will their tools and practices. If a team has historically procrastinated getting started on a new development effort, consider executing these activities in Sprint 1. The timebox will force the team to produce an increment of working functionality in the same Sprint that they set up their environment. In other words, their tooling will be barely sufficient.
Note The concept of the pre-game (or “Sprint 0” as some call it) does not exist in the Scrum Guide. Whatever the team wants to calls it, they are just not yet practicing Scrum. Because of this, most of the pre-game activities I’ve listed here will be out of the scope of this chapter. I will focus only on those activities directly related to provisioning the Azure DevOps environment.
Setting Up the Development Environment
It should go without saying that before a Scrum Team can begin using Azure Boards to implement Scrum, someone must provision Azure DevOps. For the cloud-hosted Azure DevOps Services, this is as simple as signing up, creating a new organization, and entering payment details. For the on-premises Azure DevOps Server, this means installing and configuring.
This section assumes that you have a properly provisioned Azure DevOps Services organization available for the team to use. I’ll also assume that you have access to a helpful organization owner or project collection administrator to serve your Scrum Team as needed. Maybe this is you, but if not, hopefully it’s someone who is a friend of the team. In my experience, this is a recipe for success. If the administrator understands software development, that’s great. If the administrator understands Scrum, that’s awesome. In my experience, if the administrator only has an IT/operations background, be prepared for some friction.
Tip Having a Scrum Team member also be the Azure DevOps administrator is not ideal. A Scrum Team should be able to focus on building great product, not administering their DevOps tools. High-performance Scrum Teams are ones whose team members can avoid being distracted by activities that don’t directly contribute to delivery of business value.
Creating an Azure DevOps Organization
The Azure DevOps organization is a mechanism for organizing and connecting groups of related projects. An organization might be a business division, a regional division, or other enterprise structure. You can choose one Azure DevOps organization for your entire company, or separate organizations for specific business units, or even teams. In other words, your business structure should act as a guide to the number of organizations that you create in Azure DevOps.
Before you begin using Azure DevOps Services, someone in your organization or team will need to sign up and create a new organization. You can use an Azure Active Directory (AAD), a Microsoft Account (MSA), or a GitHub account to sign up. It’s easy enough to create these, if you don’t happen to have one. Even if your company doesn’t yet have an AAD instance, one can be created for free by using the Azure portal. Double-check first, because having an AAD is required if your organization is using Azure or Microsoft 365 (formerly known as Office 365), so you may already have one.
AAD is the recommended choice because it’s so convenient to have your Azure DevOps Services organization backed by AAD and to be able to have everyone’s names available to select from without having to remember if someone is a live.com, hotmail.com, outlook.com, Gmail, etc. Connecting to AAD will map existing Azure DevOps users in the organization to their corresponding identities in AAD.
The Azure DevOps Services organization name will become part of the URL that individuals use to access the services. The organization URL uses the format https://dev.azure.com/{organization}. For example, since my organization name is Scrum, the URL to access the services is https://dev.azure.com/scrum. This is something to consider if your company’s name is Fabrikam Fiber and Cable Management Limited. Perhaps just shrinking it to Fabrikam would be preferred. The trick, like with web domains, is finding a short organization name that is not taken. At any time, an organization administrator can rename the organization to a better name and, thus, a better (hopefully) simpler URL.
Note A default project collection is created when you sign up with Azure DevOps Services. However, unlike the on-premises Azure DevOps Server (or Team Foundation Server), the existence of the collection has been abstracted out of the URL and UI. In other words, you don’t even have to worry about it. The cloud-based Azure DevOps Services URLs are shorter and you probably won’t miss what you never knew existed.
For a larger company, you can create multiple organizations. For example, the Fabrikam company might create three Azure DevOps organizations: Fabrikam-Marketing, Fabrikam-Engineering, and Fabrikam-Sales. The organizations are all for the same company but are mostly isolated from each other. Each organization has a separate URL, a separate list of users, a separate subscription. Setting up boundaries like this is not required, but it is helpful if and when doing so makes sense.
When you create an organization, you can also choose the Azure region where your organization is hosted. You may choose your organization's region based on locality and network latency, or because you have sovereignty requirements for specific data centers. You can see an example of this in Figure 4-1. A default location is selected, based on the closest Microsoft Azure region where Azure DevOps Services is available.
FIGURE 4-1 Select the region where a new Azure DevOps organization will be created.
Note Azure DevOps Services maintains all of your data within the selected Azure region, including work items, source code, and test results. Geo-redundant mirrors and offsite backups are stored within the region as well. Azure DevOps Services stores information that is more global in nature, such as user identities and profile information, in either the U.S. data center (for U.S.-based users) or the EU data center (for EU-based users). Profile data for users from all other countries are stored in the U.S. data center.
Providing Access to the Organization
After the organization has been created, with the best name, in the best region, it’s time to make additional settings so that your teams, team members, and stakeholders can access it. This step will involve adding them as users, specifying their AAD or MSA credentials, selecting the type of license, and providing access to one or more projects. This step also involves setting up billing to pay for the user licenses, self-hosted and additional pipeline jobs, and other services.
To review, the following types of users can join your organization for free:
■ Five users who get Basic features
■ An unlimited number of Visual Studio subscribers who get Basic features, and possibly Basic + Test Plans and self-hosted parallel jobs
■ An unlimited number of users who get Stakeholder features
Users not listed here must have a Basic or Basic + Test Plans license purchased for them. You do this through user assignment–based billing, where you will pay for the users who are assigned a specific access level. When a user is removed, those charges stop. You can set the organization default to Stakeholder access so that once you run out of user assignment–based licenses, each new user will be assigned a free Stakeholder license. This way, there aren’t any users who are not assigned a license, and every new user gets at least some access to Azure DevOps. You can see user license assignment starting to emerge in Figure 4-2.
FIGURE 4-2 You can add organizational users and assign them licenses.
Tip Although it is possible to add users to the organization directly, it makes more sense to do so once a project is created. This way, you can add them and assign a project role all in one step. In fact, most of the interesting configurations I will look at, as they relate to Professional Scrum Teams, are done at the project level, as you will see later in this chapter.
Before you can purchase a Basic or Basic + Test Plans license or any other paid service, you must set up billing. All billing is done through Azure; therefore, you will have to set up an Azure subscription. Even though you may not be using Azure or any other Azure service, this is how Azure DevOps is billed. Payment options include credit card as well as invoiced billing through the Enterprise Agreement, Cloud Solution Providers, and other programs. All charges appear on a monthly Azure bill. In addition to being an Azure DevOps organization owner or collection administrator, you must be added as an owner or contributor to the Azure subscription that will be used for billing.
Tip Check out the Azure calculator to predict monthly Azure DevOps costs. It can help management understand the costs and help with their expenditure decisions. You can find it at https://azure.microsoft.com/pricing/calculator.
Microsoft offers a multi-organization billing option, which allows you to pay once per user, regardless of the number of organizations they belong to. Multi-organization billing simply groups the per user charges at the subscription level, so only organizations that share a common Azure subscription can be billed together.
Multi-organization billing does not make sense for all customers. For example, each organization gets five free Basic users, which apply to the billing subscription, not the organization. If most of the users access only one organization, then five free users may be more cost-effective. If many users access multiple organizations, then multi-organization billing is likely the better option.
Smell It’s a smell when I see members of a professional software development team being assigned Stakeholder access. Although it may be adequate for some stakeholders, every member of a Scrum Team requires at least Basic, if not Basic + Test Plans access. The (free) price of Stakeholder access is tempting to management, but it tends to reflect their inability to value what the team does or how they do it.
Other Organization Configurations
Creating the organization, setting up billing, and providing user access are the primary steps in provisioning an Azure DevOps Services environment. Some of those activities are ongoing, such as when team members join or leave the development effort or new stakeholders desire access.
Here are some of the other configuration and administrative activities that may be pertinent to setting up your Azure DevOps environment:
■ Auditing Access, export, and filter audit logs that list all changes that occur throughout the organization. Changes occur when a user or service identity edits the state of an artifact, like changing permissions, deleting resources, changing branch policies, and so on.
■ Global notifications Enable organization-wide notifications by configuring default subscriptions, subscribers, and other settings.
■ Usage Investigate and view high usage levels by you and other users in the organization.
■ Extensions View and manage extensions that have been installed, requested, or shared. Extensions will be discussed later in this chapter.
■ Security - Policies View and manage various application connection, security, and user policies.
■ Security - Permissions View and manage organization-level permission groups and permissions, such as specifying which users can help with organization- and collection-level administrative activities.
Tip The user who created the Azure DevOps organization becomes the organization owner. The organization owner is also a member of the Project Collection Administrators group and cannot be removed. The owner can be changed, however. Also, to reduce the risk of losing admin access, you should add additional users to the Project Collection Administrators permission group. As roles and responsibilities change, you can change owners.
■ Boards - Process View and manage system and inherited processes. I covered this in Chapter 3, “Azure Boards.”
■ Pipelines - Agent pools View and manage the agent pools, which are containers that logically group one or more build/release pipeline agents, for your whole organization.
■ Pipelines - Settings View, enable, and disable various pipeline settings, such as limiting variables that can be set at queue time.
■ Pipelines - Deployment pools View and manage the deployment pools, which are containers that logically group one or more deployment targets, such as the servers in a test environment.
■ Pipelines - Parallel jobs View and manage the number of in-progress jobs as well as the maximum number of parallel jobs available.
Note For each parallel job listed, you can run a single job at a time in your organization. Microsoft-hosted job limits are separate from self-hosted (on-premises) job limits. The free tier limits include one Microsoft-hosted pipeline and one self-hosted pipeline (with no hour limits). Additional parallel jobs can be purchased for both Microsoft-hosted and self-hosted environments.
■ Pipelines - OAuth configurations View and manage OAuth-based service connections to third-party services, such as GitHub, GitHub Enterprise Server, and Bitbucket Cloud.
■ Artifacts - Storage View and manage your usage of pipeline artifacts and packages stored in Azure Artifacts feeds.
Azure DevOps Marketplace Extensions
Microsoft knew early on that they would not be able to keep up with the development community’s demand for Azure DevOps features and customizations. Shadow groups within Microsoft created and blogged freely downloadable tools. Even Microsoft Research gave us some great toys over the years, a couple of which ended up inside Visual Studio Enterprise edition. We also had CodePlex and GitHub, which were good ways of sharing open source plug-ins and extensions. The support was great, but we lacked a centralized marketplace, as Visual Studio had with its Visual Studio Gallery.
Seeing the success of the Eclipse marketplace and numerous other app stores, Microsoft decided to offer something similar. At the Connect() event in November 2015, Microsoft launched the Visual Studio Marketplace, which replaced the Visual Studio Gallery. At the same time, they also launched the Visual Studio Team Services Marketplace. They added support for the on-premises Team Foundation Server the following spring. Since then, we’ve enjoyed a unified marketplace full of wonderful extensions published by Microsoft, Microsoft partners, and the community at large.
Today, the Azure DevOps Marketplace boasts more than 1,200 extensions across all the services: Azure Artifacts, Azure Boards, Azure Pipelines, Azure Repos, and Azure Test Plans. You can search for extensions that work in the cloud (Azure DevOps Services) or on-premises (Azure DevOps Server) as well as by other factors, such as price and certification. For example, Figure 4-3 shows the first page of Azure Boards extensions for Azure DevOps Services sorted by number of installations.
FIGURE 4-3 There are many great Azure Boards extensions in the Azure DevOps Marketplace.
Extensions for Professional Scrum Teams
Ultimately, which extensions a Scrum Team wants to install and use should be up to the team. In the spirit of experimentation, inspection, and adaptation, they should install and evaluate an extension, using it minimally for one to three Sprints in order to form an opinion on its value. At the next Sprint Retrospective, the Scrum Team can share their findings and decide if they want to keep using it, change the way they are using it, or drop it. Although this applies particularly well to extensions, this should be the approach that a Scrum Team takes with all tools and practices they experiment with.
Over the many years training, consulting, and coaching Scrum Teams, I’ve come up with a list of some extensions that have proven themselves valuable. I’m not saying that my list should be your list. In fact, you may think some of these are less useful than I do. You may also find other extensions that are awesome and can really enable your team. Just be sure to inspect their value and adapt their usage accordingly.
Here’s my partial list of extensions that have proven themselves valuable in the visualization and management of work for Scrum Teams (in no particular order):
■ Azure DevOps Open in Excel Opens work items and query results in Excel from Azure DevOps. Requires Excel and Azure DevOps Office Integration to be installed.
■ CatLight Notifies Developers in the system tray when pull requests, builds, bugs, and tasks need their attention.
■ Decompose Allows you to quickly break down work items from epics to features to PBIs to tasks. Use keyboard shortcuts to easily promote and demote work items between different hierarchy levels, as shown in Figure 4-4.
FIGURE 4-4 Use the Decompose extension to quickly create work item hierarchies.
■ Definition of Done Lets you view and modify your team’s Definition of Done. Visualize this definition on each PBI work item, and even use it as a confirmation step before setting the work item to the Done state.
■ Feature timeline and Epic Roadmap Allows you to plan or track work items in progress by visualizing them on a Sprint calendar. This tool helps you visualize the portfolio-level work items (epics and features) as they are worked over multiple Sprints. Microsoft won’t be investing further in this extension, especially once their Delivery Plans 2.0 extension is published.
■ Product Vision Allows the Product Owner to easily set the product vision and make it visible to team members and stakeholders.
■ Retrospectives Enables the collecting, grouping, voting, and visualizing of feedback obtained during a Sprint Retrospective.
■ SpecMap Lets you create engaging story maps directly from the work items in Azure Boards. Use these story maps to visualize user journeys, refine PBIs, and plan releases.
■ Sprint Goal Enables the Scrum Team to display a Sprint Goal on the Sprint page.
■ Tags Manager Lets you manage work items tags by viewing, renaming, merging, and even deleting them in a central place.
■ Team Calendar Allows you to track the events important to the team, view and manage days off, quickly see when Sprints start and end, and more.
■ ActionableAgile Analytics Lets you analyze and display many aspects of a team’s development process. This extension uses the team’s own data to predict when specific PBIs might be completed, when a release might be ready, or how many PBIs might be in a release.
■ Test & Feedback Supports running manual or exploratory tests. This browser-based extension can capture notes, screenshots with annotations, screen recordings, user actions (as an image action log), page load data, and other system information. This rich data can be associated with work items that are created, such as issues, tasks, and feedback response work items.
As you can tell, this list of extensions is primarily Azure Boards and Azure Test Plans related. This is not to say that Scrum Teams can’t make use of some great extensions in other categories. There are plenty available too. I just wanted to focus on those extensions that dealt with viewing and managing work, and not any particular development or engineering practices.
Note Only organization owners and Project Collection Administrators can install an extension. If you don’t have those permissions, you can request an extension instead. You must be a contributor for your organization in order to request an extension. You can view and monitor your requested extensions on the Requested tab in the Extensions page. An administrator can then approve (and thus install) the extension. Hopefully the delay in requesting and approving is minimal. Delays like this are proportional to how agile your organization is (or isn’t).
Fabrikam Fiber Case Study
The Scrum Team has considered the many extensions in the marketplace and will be installing and using the ones mentioned in this section. Since Scott, the Scrum Master, was added as a Project Collection Administrator, he can install and configure these extensions without delay.
Setting Up Product Development
This section explores those activities related to setting up software product development within Azure DevOps. Some of these activities are one-time events, whereas others are ongoing, such as configuring areas and iterations. Before proceeding, it’s assumed that the following activities have already been completed:
■ You have a product with goals and stakeholders.
■ The Scrum Team has been formed and roles identified.
■ All team members are in the company’s Azure Active Directory (AAD) or have Microsoft Accounts.
■ An Azure DevOps Services organization has been created and backed by AAD, and billing details have been entered.
■ Appropriate Azure DevOps licenses have been purchased for the team members.
■ Azure DevOps extensions have been installed.
■ Appropriate client software has been installed (for example, Visual Studio, Visual Studio Code, Microsoft Office).
Creating a Project
The Azure DevOps project is the container for the software product’s development lifecycle. All work items, code and other version-controlled artifacts, test cases, test results, pipelines, builds, and releases are stored in a project. Technically, they are stored as a combination of Azure SQL table data and blob storage. To look at it from a Scrum perspective, the Azure DevOps project represents the product being developed and is a container for the Product Backlog, the Sprint Backlog, the source code, and the tests that form the Increment and thus the product. The project also contains queries, charts, and other visualizations that enable a team to assess their progress and the quality of their work.
Note You may have noticed that I don’t refer to “team project,” just “project.” For whatever reason, the “team” prefix has been disappearing from usage over the past few years. You can still find “team project” and “team project collection” (Azure DevOps Server) referenced in the product and docs, but for the most part, the world seems to have dropped the “team” prefix. If you find out why, let me know.
You can create a new project on the Projects page of Organization settings. You will need to provide the name and description of the project and select the visibility, version control system, and process, as I’m doing in Figure 4-5. By default, only organization owners and Project Collection Administrators can create a new project.
FIGURE 4-5 We create the Fabrikam project using a custom Professional Scrum process.
The name of the project should be short and simple, and relate to the product being developed. The name does not need to include the version, release, Sprint, team, feature set, area, or component. All of these items can be tracked within the project using areas, iterations, teams, and repositories. For example, if I were creating a project to plan and track development of the Fabrikam application, I would consider naming it something simple like Fabrikam rather than FabrikamV1, FabrikamBeta, FabrikamSprint1, FabrikamDev, or FabrikamWeb.
Creating a project is the easy part, but planning it can be more difficult. It’s imperative that you know what product—or component of a larger product—that your team will be developing. If the product has a name, you should consider using that for the name of the project. If the product doesn’t yet have a name, or the name is something like “The web app that consumes the web service from our financial partner,” you’ll want to give it an actual name first. This is the first step in it becoming a product. It sounds trivial, but having a clear, meaningful name will begin the process of focusing less on how the software works and more on what it should be doing. If you are at a complete loss, then consider Wikipedia’s page listing fictional computer names at https://en.wikipedia.org/wiki/List_of_fictional_computers for inspiration.
Smell It’s a smell if the Developers don’t know the name of the product they are developing. Maybe it doesn’t have a name, or maybe they just don’t care to know it. Either way, this demonstrates a lack of product-minded thinking. For a successful adoption of Scrum to occur, this must change. The Scrum Master and Product Owner can help with this.
Determining How Many Projects You Will Need
The answer is almost always one, as I’ll explain.
The scope of an Azure DevOps project is a function of the product being developed, its components, the number of Developers, and whether they are dedicated to that one product. Developers include anyone who performs analysis, design, coding, testing, deployment, operations, or other activities that help turn a PBI into done, working software. The ideal formation is a Scrum Team of no more than 10 members dedicated to working on a single product. This would simply require one project containing both the Product Backlog and the engineering aspects (repositories, pipelines, and feeds) of the product being developed.
Unfortunately, I don’t see this very often. More often I come across tiny teams, huge teams, or teams having to context-switch across multiple products and domains. Good’ish news here: Azure DevOps can support all of these environments as well.
On a micro-team of only one or two Developers, they won’t necessarily be practicing Scrum, but they could still make use of an Azure DevOps project. I would hope they would take advantage of the Product Backlog, but as far as planning and tracking work within a Sprint, they may not need tooling for that. For medium-large teams with 10 or more developers, they would want to split into smaller, correctly sized Scrum Teams to work more efficiently within the rules of Scrum. They can still all work within the same Azure DevOps project. Table 4-1 shows a summary of this discussion.
TABLE 4-1 Azure DevOps Projects Based on Teams and Products.
Developers |
Products |
Azure DevOps projects |
Notes |
1–2 |
1 |
1 |
|
|
> 1 |
1 |
|
3–9 |
1 |
1 |
|
|
> 1 |
1 |
|
10–18 |
1 |
1 |
|
10+ |
> 1 |
Varies |
|
19+ |
1 |
1 |
|
I’ve seen large products with 80+ developers working within the same Azure DevOps project and using a single backlog. This increased complexity demands using work item areas to designate the responsible team, not to mention being deliberate about using—and naming—the corresponding repositories and pipelines. Even developers in the unfortunate situation of having to develop or support multiple products at the same time can still do so within one project—by having a single backlog from which to order and plan the work.
Fabrikam Fiber Case Study
Scott created an Azure DevOps project named Fabrikam based on the custom, inherited Professional Scrum process. The Fabrikam project is a private project using Git version control.
One organization I worked with claimed to be using Scrum. It had multiple product managers, each vying for the team’s time. Needless to say, its queue of work was quite full, always changing, and always being reprioritized. Focus was low. Chaos was high. One product manager wanted a set of improvements on their system and asked the IT director when she could have them. The IT director performed some high-level analysis and provided a rough estimate, telling the manager that work could be started in about 9 months and, once started, shouldn’t take longer than about a month. The manager was displeased. She asked if the team could start sooner and work on her features in between their other tasks. The IT director replied, “We can do that, but then it will take us 12 months total, put other projects behind, and you won’t like the quality of our work.”
The IT director was describing the fundamental result of Little’s law, which is that for a given process, in general, the more things that you work on at any given time (on average), the longer it is going to take for each of those things to finish (on average). The IT director realized that the manager, as well as the organization, had a belief in magic. They thought that the team could work efficiently on multiple things at once; could work at an unsustainable pace when it suited the organization; and could give accurate estimates for unknown, complex problems. Eventually, the IT director became the Product Owner and was able to order the work in a way where the team could focus, spending an entire Sprint working on the most important work—as decided by the Product Owner, not the cadre of managers.
Tip If your development organization is broken and can’t be fixed, rest assured that Azure DevOps can implement whatever dysfunctional processes you can throw at it. For a situation where a small number of Developers must service a large number of products in a prioritized, just-in-time way, then I suggest they take a look at Kanban. Kanban is a method for developing software with an emphasis on just-in-time delivery. Kanban instructs developers to pull work from a queue using a visual board that shows the work in progress by state. It can better support unplanned work.
Adding Project Members
When a project is first created, only the creator is a member. They will need to add other team members. This can be done in one step as a new Azure DevOps user is added from the organization’s Users page. For an existing user, a Project Administrator (e.g., the person who created the project) will need to add them directly to the project.
Project members can be added via the Permissions page, assigning them to one of the built-in groups. You can see these groups in Figure 4-6. Members can also be added to a team (which in turn is a member of a permission group). I’ll talk about teams in a bit. If you’re adding a user to Azure DevOps for the first time, you’ll need to add them as an Organization user first.
FIGURE 4-6 The Permissions page shows the groups in the Fabrikam project.
Projects contain several project-level permission groups—each with a default set of permissions. These are created at the time the project is created, and they are all empty. The exceptions are the Project Administrators and Project Valid Users groups, which contain the user who created the project. These groups are populated by the user who created the project, who is also typically a Project Collection Administrator. The Project Administrator must decide who else needs access to the project and what level of permission they need.
Here are details about the built-in permission groups:
■ Build Administrators Members of this group have permissions to administer build resources and build permissions for the project. Members can manage test configurations/environments, create test runs, and manage builds.
■ Contributors Members of this group have permissions to contribute fully to work items, code, and pipelines. Contributors don’t have permissions to manage or administer resources.
■ Deployment Group Administrators Members of this group have permissions to administer deployment groups and agents.
■ Project Administrators Members of this group have permissions to administer all aspects of the project and teams.
■ Project Valid Users This group contains all users and groups that have been added anywhere within the project. You cannot directly modify the membership of this group.
■ Readers Members of this group have permissions to view project information, work items, code, and other artifacts but not modify them.
■ Release Administrators Members of this group have permissions to manage all release operations.
■ <Project> Team The project’s default team is also considered a permission group. It can have membership and be assigned permissions like the other groups. I’ll get into more details on teams in a bit.
According to Microsoft’s design and documentation, the obvious choice would be to add all the members of the Scrum Team (including the Product Owner and Scrum Master) to the Contributors group, stakeholders to the Readers group, and a select few to the Project Administrators group. Although I acknowledge that this is a valid choice, I believe that it can lead to impediments during a Sprint. For example, if the Project Administrator is unavailable, the team members might be blocked from adding a new work item area, creating a shared query, or adding a new team member. These sound like minor things, but they can add up to a fair amount of waste during the course of a Sprint.
I believe that if a team has a certain level of proficiency in the tool, and the members trust one another, they should all be added to the Project Administrators group. This epitomizes the self-managing qualities of the Scrum Team. You can easily do this by making the team (for example, Fabrikam Team) a member of the Project Administrators permission group, after which you can remove the team from the Contributors group. You can see the final result in Figure 4-7.
FIGURE 4-7 We can make the Fabrikam Team a member of the Project Administrators group.
Fabrikam Fiber Case Study
After Scott created the Fabrikam project, he made the default Fabrikam Team a member of the Project Administrators group. He also removed the Fabrikam Team as a member of the Contributors group, since that was no longer required. Scott then added all the Scrum Team members to the Fabrikam Team and then added two key stakeholders, Jake and Yuri, to the project’s Readers permission group. During upcoming Sprint Retrospectives, the team will discuss and decide if any permission levels need to be adjusted for any team members or stakeholders.
Teams
Teams are similar to permission groups but with added capabilities when it comes to using the agile planning tools in Azure Boards. Like groups, teams allow the organizing of collaborating individuals who will be working on similar areas of the product. Teams differ from groups in that they enable their members to access and use the agile planning tools in order to define and manage their Product Backlog, Kanban board, Sprint Backlog, and task board. By default, a new team has the same permissions as the Contributors permissions group.
When a project is created (such as Fabrikam), a default team is created with the same name as the project. Team members can be added to this team and start using the agile planning features right away, without the need for additional configuration. In scaled product development situations, like with the Nexus Scaled Scrum framework, a Project Administrator can create additional teams, giving them each a custom view of the overall Product Backlog. I cover this in Chapter 11, “Scaled Professional Scrum.”
Azure DevOps allows a user to belong to more than one team. Before considering this as an option, make sure that it would be prudent. Rarely do team members belong to more than one Scrum Team, especially within the same product. If the team member is shared between a couple of teams, then this might make sense, but let’s think about it. Forget about Azure DevOps supporting it or not and consider it from a commitment and focus perspective. Is it really the best use of this person’s time to be physically and mentally switching teams and context like this? You’ll learn more about this in Chapter 8, “Effective Collaboration.” Perhaps other alternatives could be considered during the next Sprint Retrospective. If you are thinking that you should add the Product Owner and Scrum Master to multiple teams, don’t. This is exactly the purpose of the default team. Members of the default team can see all the items in the Product Backlog. I cover this in Chapter 11.
Note When you create a new team, Azure DevOps can also create a similarly named area path at the same time. This ensures a strong connection between teams and areas, as you can see in Figure 4-8. You can skip this when creating a new team by clearing the Create An Area Path With The Name Of The Team check box. Also, keep in mind that if you rename your team, it will not rename the associated area path. You must do that manually. The default team’s area is the root enabling team members to view and manage the entire Product Backlog.
FIGURE 4-8 We can create a corresponding area path when creating a new team.
After creating a team, its iterations (Sprints) and areas can be specified. Iterations that the team selects will appear in the backlogs as Sprints for the sake of forecasting and planning. The areas that a team specifies determine what work items show up in the team’s backlog. Teams can also designate one of those areas as its default. This is then suggested when creating new work items.
The user who created the team becomes the Team Administrator. Team Administrators can manage the team and team membership, as well as configure the agile tools. Essentially, Team Administrators can configure, customize, and manage all team-related activities for their team. Each team must have at least one Team Administrator. To remove a Team Administrator, you must first add a second Team Administrator before you can remove the first Team Administrator.
Here are some of the activities that a Team Administrator can perform:
■ Create and manage team alerts
■ Select team area paths
■ Select team Sprints
■ Configure team backlogs
■ Customize the Kanban board
■ Manage team dashboards
■ Set working days off
■ Show bugs on backlogs and boards
Note It’s easy to confuse Project Administrator with Team Administrator. Whereas the Project Administrator is a permission group with a set of permissions, the Team Administrator is a role that is tasked with managing team assets. A team member can be both a Team Administrator and a member of the Project Administrator role, which (as you can probably guess) is what I recommend for every member of the Scrum Team.
Fabrikam Fiber Case Study
To further limit impediments and reinforce self-management, Scott makes sure that every member of the Scrum Team is not only a Project Administrator, but also a Team Administrator of the Fabrikam Team. You can see this in Figure 4-9. During upcoming Sprint Retrospectives, the team will discuss and decide if any permission levels need to be adjusted for any team members or stakeholders.
FIGURE 4-9 Each member of the Fabrikam Scrum Team has been made a Team Administrator.
Other Project Configurations
Creating the Azure DevOps project, configuring permissions, and adding team members are the most important provisioning steps. Some of those activities are ongoing, such as when team members join or leave the development effort or new stakeholders need access. You should rarely have to futz with the groups and permissions, however.
Here are some of the other configuration and administrative activities that may be pertinent to setting up a project:
■ Azure DevOps services By default, all of the Azure DevOps services (Boards, Repos, Pipelines, Test Plans, and Artifacts) are enabled. A Project Administrator may want to disable, or later reenable, some of these services if they won’t be used during the development effort.
■ Notifications Enable project-wide notifications by enabling/disabling subscriptions, adding new subscriptions, or changing delivery settings.
■ Service hooks View and manage integrations with other Microsoft or third-party services, such as App Center, Azure, Teams, Microsoft 365, or UserVoice.
■ Boards - Project configuration View and manage the iterations (Sprints) and areas for the project. Figure 4-10 shows the Sprints set up for this project. Figure 4-11 shows the areas set for this project. Since there is only one team—the Fabrikam Team—it will use all iterations and areas.
FIGURE 4-10 The first five Sprints have been created, each with a two-week duration.
FIGURE 4-11 Area paths reflect the logical or functional areas of the product.
■ Boards - Team configuration View and manage the backlog behavior, working days, bugs behavior, iterations, areas, and work item templates for each team.
■ Boards - GitHub connections Manage GitHub integration with Azure Boards.
■ Repos - Repositories View and manage permissions, options, and policies for the project’s repositories.
■ Repos - Cross-repo policies View and manage pull request completion requirements for branches that match a pattern across all of your repositories.
■ Pipelines - Agent pools View and manage agent pools, which are containers that logically group one or more build/release pipeline agents, for your project.
■ Pipelines - Parallel jobs View and manage the number of in-progress jobs as well as the maximum number of parallel jobs available.
■ Pipelines - Settings View, enable, and disable various pipeline settings, such as limiting variables that can be set at queue time and retention policies.
■ Pipelines - Test management View and manage flaky test detection. A flaky test is a test that provides different outcomes, such as pass or fail, even when there are no changes in the source code or execution environment.
■ Pipelines - Release retention View and manage release retention policies.
■ Pipelines - Service connections View and manage connections and authentication details to a number of services, such as Azure, Chef, Docker, GitHub, Jenkins, Kubernetes, Nuget, Npm, and more.
■ Test - Retention View and manage automated and manual test retention policies.
Establishing Information Radiators
An information radiator is a generic term for any kind of display—physical or electronic—placed in a highly visible location that shows process or product information. Information radiators can be for the Scrum Team and/or stakeholders. Azure DevOps offers several information radiator solutions. Every Azure DevOps project has an Overview hub, which contains a summary page, one or more dashboards, and a wiki, which can contain multiple pages. Even if a project has all the Azure DevOps services (Azure Boards, Azure Repos, etc.) disabled, the Overview hub and those pages remain. Initially, the Overview hub is pretty boring. It’s up to the team to decide what interesting and valuable content should be added.
Here’s a quick look at each of these pages:
■ Summary This simple welcome page for the project shows high-level information such as project stats and team members.
■ Dashboards These customizable, interactive signboards provide real-time information. Dashboards can be associated with a team and display configurable charts and widgets.
■ Wiki The team can create wiki pages and share information with your team in order to better understand and contribute to your project.
Summary Page
The Summary page isn’t all that interesting. It cannot be customized to the extent of being an effective information radiator, but it does have its purpose. It is the landing page for the project, so it should effectively communicate the purpose of the project and development effort.
To customize the Summary page, you basically have two options. First, if you have Azure Boards enabled, you can simply add a project description (yawn). Second, if you have Azure Repos enabled, you can point the Summary page to the home page of your wiki or to a readme file full of Markdown goodness, as I’ve done in Figure 4-12.
FIGURE 4-12 This Summary page points to a readme Markdown file in the repository.
Dashboards
Dashboards are a great way for a team or stakeholders to visualize real-time information about the product or process. They are visually appealing, interactive, and customizable. A project can host several dashboards, each serving a specific purpose.
Each dashboard hosts an array of widgets. Widgets display specific information, such as query results, charts, team members, statistics, shortcuts, Markdown, or even an embedded webpage. You can see an example of this in Figure 4-13. Widgets can be resized and configured in a number of ways. Over two dozen widgets are available out-of-the-box and more than a hundred available through the Azure DevOps Marketplace. Dashboards can be configured to periodically refresh their contents.
FIGURE 4-13 You can add widgets to the Overview dashboard.
Note Widgets that pertain to a specific Azure DevOps service are disabled if the service they depend on has been disabled. For example, if the Azure Boards service is disabled, work tracking–related widgets are disabled and won’t be selectable.
When you create a dashboard, you can choose to make it a project dashboard or one specific to a team. Project dashboards display information or status about the project. Project dashboards also have configurable permissions. Team dashboards provide focused information specific to that team. For Azure DevOps projects that only have one team—the default team—project dashboards work just fine. For Azure DevOps projects in a scaled environment (e.g., using the Nexus Scaled Scrum framework), it might make sense for each team to have their own dashboard radiating their own information.
Here are some of widgets that a Professional Scrum Team may be interested in:
■ Burndown Displays burndown by backlog level or work item type, either by count of work items or sum of Business Value, Effort, or Remaining Work. Configurable by team, date range, and other criteria.
■ Burnup Displays burnup by backlog level or work item type, either by count of work items or sum of Business Value, Effort, or Remaining Work. Configurable by team, date range, and other criteria.
■ Chart for Test Plans Tracks the progress of test case authoring or status of test execution for tests in a test plan. Several chart types and settings are available; this widget is intended for use by teams using Azure Test Plans.
■ Chart for Work Items Displays a progress or trend chart that builds off a shared work item query, such as showing investment by product area. Several chart types and settings are available.
■ Cumulative Flow Diagram Displays the flow of work through the system for a specified team, backlog, and timeframe. Primarily for Kanban teams, but since Scrum Teams can practice Kanban as well, this widget can be very helpful for visualizing and improving a team’s flow. Configurable by team, backlog, swimlane, column, and date range. I cover this in Chapter 9, “Improving Flow.”
■ Cycle Time Used to monitor the flow of work through a system by computing the amount of time a team spends actually working on a PBI from start to finish. Primarily for Kanban teams, but since Scrum Teams can practice Kanban as well, this widget can be very helpful for visualizing and improving a team’s flow. Configurable by team, backlog, swimlane, column, date range, and other criteria. I cover this in Chapter 9.
■ Markdown Enables custom text, links, images, and more by using Markdown syntax. The widget can also be configured to point to a file stored in a repository.
■ Sprint Burndown Displays work burndown for a Sprint by backlog level or work item type, either by count of work items or sum of Remaining Work. Configurable by team, date range, and other criteria.
■ Velocity Helps to improve forecasting by displaying a team’s velocity either by count of work items or sum of Effort, Business Value, or Remaining Work. Configurable by team, backlog level, work item type, date range, and other criteria, this widget is intended for use by teams using velocity.
Fabrikam Fiber Case Study
Paula has decided to simplify the Overview dashboard to show only the product vision. She installed the Product Vision extension by Agile Extensions. This allows her to simply enter the vision and then configure a size and color scheme. You can see the results in Figure 4-14. The Product Vision can also be viewed on a Product Vision page in the Boards hub.
FIGURE 4-14 This Overview dashboard shows the Product Vision widget.
Wiki
Every Azure DevOps project has its own wiki. The wiki behaves like most other wikis you have probably used. You can use it to share information and collaborate with your team. Even stakeholders (with Stakeholder access) can view information in the wiki. The project wiki must be created before you can use it.
Behind the scenes, each wiki is supported by a Git repository. When you create the project wiki it will, in turn, provision a hidden Git repository to store the corresponding Markdown files and related artifacts. Even if your project uses TFVC for source control, it will still create a hidden Git repository to support the wiki. This is why users with Stakeholder access can’t create or edit wikis; they have no capability to work in Azure Repos.
Here are some items that a Professional Scrum Team might consider publishing in the wiki:
■ Sprint Goals
■ Sprint Retrospective notes
■ Definitions (Done, ready, bug, etc.)
■ Development standards and practices
■ Stakeholder contact list
■ Technical documentation and notes
For some of these items, sticky notes or writing on a whiteboard would work just fine, and possibly be even more visible. Physical boards fall apart when it comes to broad visibility, searching, and fault tolerance (e.g., the nightly cleaning person). Also, if you want to track changes or control access of who can change these items, an electronic solution is preferred.
Tip A team should not hide its Sprint Goal or its definitions. Because transparency is important, make these broadly available so that all stakeholders know what you are working on and what your definitions are—especially your Definition of Done. In addition, teams may want to increase transparency by publishing their metrics (burndowns, velocity, cycle time, cumulative flow diagram, etc.) charts and other visualizations. For the ultimate in transparency—and courage—you could even publish these on a large flat screen in the break room or cafeteria. Now that’s confidence!
The wiki makes a great place to store your team’s definitions, such as the Definition of Done. You can see an example of this in Figure 4-15. By making this and other definitions big and visible, a Scrum Team’s transparency increases, as well as a shared understanding of the work that the Scrum Team is performing. Stakeholders, knowing what the team’s Definition of Done is, will be informed the next time a Developer says that they are “done” or “not done” with something. There’s an actual checklist, on the wiki, available to all, that describes what “done” means.
FIGURE 4-15 The wiki lets you share your team’s Definition of Done.
Fabrikam Fiber Case Study
The Scrum Team has decided to use the wiki for sharing information with one another as well as stakeholders. As part of that, they have created a wiki entry to track their Definition of Done. They will also create separate wiki entries for Sprint Goals and Sprint Retrospectives.
Pre-game Checklist
Each team and organization’s preparation will be different. Those just getting started with Scrum and/or Azure DevOps may have more work to do in their pre-game. Other teams can basically just start with their first Sprint. Regardless of where you and your team are, this checklist can be helpful in preparing your environment for an awesome first Sprint.
Scrum
❒ Identify the product.
❒ Establish the vision, scope, and business goals of the product.
❒ Identify product sponsors and stakeholders.
❒ Define the high-level product requirements.
❒ Establish the Scrum Team (Product Owner, Scrum Master, and Developers).
❒ Educate individuals on the rules of Scrum (if necessary).
❒ Locate the Product Backlog (if one exists).
Azure DevOps Organization
❒ Create the organization.
❒ Connect to Azure Active Directory (if necessary).
❒ Set up billing in Azure.
❒ Acquire user licenses.
❒ Add the users to the organization.
❒ Add a backup Collection Administrator.
❒ Configure global notifications.
❒ Install any extensions from the Azure DevOps Marketplace.
❒ Create a custom, inherited Professional Scrum process.
❒ Purchase additional parallel or self-hosted pipeline jobs.
❒ Create the Azure DevOps project.
Azure DevOps Project
❒ Enable/disable specific Azure DevOps services.
❒ Configure notifications.
❒ Create additional teams (if in a scaled environment).
❒ Add stakeholders to the Readers role (or, optionally the Contributors role).
❒ Configure at least the first three Sprints (iterations with consistent lengths and no gaps).
❒ Configure areas.
Azure DevOps Team
❒ Make each team a member of the Project Administrators group.
❒ Remove each team from the default Contributors group.
❒ Add users to their appropriate team(s).
❒ Make each user a Team Administrator.
❒ Choose an awesome image/avatar for the team.
❒ Configure what backlogs the team will use (Epics, Features, etc.).
❒ Configure team working days.
❒ Configure team iterations (at least the first three Sprints).
❒ Set team’s Default iteration and Backlog iteration to root.
❒ Set the team’s default area (root if only one team).
❒ Select the team’s areas (root, including subareas if only one team).
Azure DevOps User
❒ Set full name and contact email in profile.
❒ Choose an awesome image/avatar.
❒ Set time and locale information.
❒ Configure notifications.
❒ Select theme (light or dark).
Chapter Retrospective
Here are the key concepts covered in this chapter:
■ Provisioning Azure DevOps Services Before being able to use the cloud-hosted Azure DevOps, you will need to create an organization, set up billing, and acquire user licenses.
■ Azure Active Directory Azure DevOps Services can be connected to Azure Active Directory to simplify the onboarding and managing of users from your organization.
■ Extensions Adds additional functionality to Azure DevOps. Available through the Azure DevOps Marketplace, an active community of extension providers.
■ Azure DevOps project This serves as the container for your product’s lifecycle. One project can support multiple product areas, teams, Sprints, and releases.
■ Azure DevOps team This is similar to a permission group in an Azure DevOps project, but with additional context and support for using the agile planning tools.
■ Areas This hierarchy is useful for classifying work into different logical or functional areas of the product. Areas are used to help organize work items. For scaled development, each Azure DevOps team in a project can be associated with one or more areas. I cover this in Chapter 11.
■ Iterations Synonymous with Sprints, Iterations have a name, a start date, and an end date and are used to help organize and plan work.
■ Summary page This is the Azure DevOps project’s landing page. The Summary page contains basic information by default. It can be customized by pointing at a readme file or a wiki.
■ Dashboards These interactive signboards can display a variety of static and dynamic content through the arrangement of widgets. A number of widgets are available out-of-the-box, with many more available in the Azure DevOps Marketplace.
■ Wiki This contains one or more pages of content authored by the team in order to collaborate, share information, and better understand the development effort. Wikis use the Markdown language, which is a lightweight markup language with plain-text-formatting syntax. Wikis are backed by Git repositories.