Dela via

Best practices for "light-weight" Agile project management

  • Artikel

TFS 2017 | TFS 2015 | TFS 2013

Azure Boards provides a choice of Agile planning tools, many of which work in combination with each other. This article provides a get-started guide for project managers new to Azure Boards. If you and your teams want to take a minimal tracking approach to plan and manage your projects, start with this guide. Also, if you are moving from waterfall project management to Agile methods, start with this guide.

Note

If your team is committed to practicing Kanban or Scrum methods, see instead About Boards and Kanban or the tutorials for implementing Scrum.

In this article, we make the following suggestions and guidance:

  • Configure your teams to support rollup of development user stories to project management features
  • Define and work in a sprint cadence
  • Use User Stories and Features to track deliverables
  • Use your team's Feature and Product backlogs to create your product plan
  • Use tags to support queries and filtering
  • Forecast your product plan to gain insight into when deliverables can ship, set milestones
  • Manage dependencies by linking work items
  • Assign work to sprints
  • Review progress and deliverables using the Features backlog, rollup, and delivery plans
  • Engage with process improvement during sprint planning and retrospectives

Note

This article applies to Azure DevOps Services. Most of the guidance is valid for both the cloud and on-premises versions. However, some of the features included in this article, such as Rollup, Analytics, and some portfolio planning tools, are only available for the cloud at this time.

Configure your teams

Azure Boards provides each team a set of Agile tools to plan and track work. Each project defines a default team, which you can start using immediately. However, if you have a number of development or feature teams, we recommend that you define a team in Azure DevOps for each feature team. This way, each team can work autonomously while collaborating with each other.

Best practice tips:

  • Configure teams along the value streams your organization wants to deliver
  • Define a team for each development group of six to twelve developers
  • Configure development teams to support rollup to project management feature teams

To learn how:

Configure your sprints

Sprints—specified by Iteration Paths—are defined for a project and then selected by teams. A sprint cadence can vary between one week to four weeks or longer. Also, you can define sprints within a hierarchy that includes release trains. You assign work to sprints that teams commit to deliver at the end of the sprint. These Azure Boards tools rely on sprint assignments to a team Sprint backlogs, Taskboard, and Forecast and Delivery plans.

Best practice tips:

  • Define a sprint cadence that all teams within your product group will use
  • Define at least six or more iterations that will support planning for the next six to twelve months
  • Determine how teams will use iterations to manage backlog items
    • Unassigned sprint work is assigned to the default backlog, or
    • Unassigned sprint work is assigned to a designated future backlog sprint.

To learn how:

Choose the work item types you'll use

Determine which work item types your team will use to capture customer requirements and development work. If your project is based on the Agile process, we recommend using User Stories, Bugs, and Features.

Note

The guidance provided in this article are based on the Agile process.

If your project is based on another process, such as Basic, Scrum, or CMMI, you have a choice from those shown in the following images. Also, each team can determine how they want to track bugs.

The following image shows the Agile process backlog work item hierarchy. User Stories and Tasks are used to track work, Bugs track code defects, and Epics and Features are used to group work under larger scenarios.

Conceptual image, Agile work item type

Each team can configure how they manage Bugs—at the same level as User Stories or Tasks—by configuring the Working with bugs setting. To learn more about using these work item types, see Agile process.

Note

Requirements specify expectations of users for a software product. In Azure Boards, requirements are defined by work items that appear on your product backlog. They correspond to User Stories (Agile), Product Backlog Items (Scrum), Issues (Basic), or Requirements (CMMI) based on the process selected for your project. They also belong to the Requirements Category which manages which work item types appear on the product backlog.

Best practice tips:

  • Use Features to capture customer features you want to ship
  • Quickly add features or requirements from the backlog and fill in details later
  • Use Requirements—User Stories (Agile), Issues (Basic) Product Backlog Items (Scrum), or Requirements (CMMI)—to break-down Features into work the development team will own
  • Use Bugs to capture code defects
  • Map Requirements to Features to track progress at the project management level
  • Size Requirements to be completed within a sprint
  • Size Features to be completed within a sprint or several sprints
  • Size Epics to be delivered quarterly or to some milestone objective
  • Let Developers use Tasks to break-down their work as needed.

As project managers, you manage the Features and the development team manages the Requirements. By mapping them using parent-child links, you gain visibility into the progress of your features. Each work item you add to your team backlog is automatically assigned the default area path and iteration path set for your team.

If you have larger initiatives or scenarios that require shipping several Features, you can group these under Epics, again using parent-child links.

To learn how:

Create your product plan

Create your product plan using the Features Backlog. The development team then creates their product plan using the Product Backlog. Periodically you'll want to review and groom your product plans.

Features backlog

Project managers initiate the product plan by adding features to the Features backlog. Each feature should represent a shippable deliverable that addresses a customer need.

Screenshot of Features backlog.

Product backlog

Development teams add User Stories to their product backlog so that the User Story is automatically assigned the team's default Area Path and Iteration Path. Then, they can map those stories under each Feature that represents the work they'll do to implement the Feature. Each User Story should be sized so that they can be completed within a sprint.

Screenshot of Product backlog.

Groom each backlog

Periodically review each backlog to perform these tasks:

  • Define work to be performed
  • Reorder work items using drag-and-drop so that they appear in priority order
  • Open work items and add details
  • Assign work to team members or to sprints
  • Capture technical debt and non-feature work required to support a healthy ecosystem of delivery
  • Map unparented work to the Feature they belong to
  • (Optional) Estimate size of requirements to help determine team velocity and support forecasting

Tip

You can monitor team velocity based on estimates assigned to completed work or a simple count of work items completed during sprints. However, to use the Forecast feature, you must assign a value to the Story Points, Effort, or Size field. If you don't want to estimate requirements, you can simply assign a value of 1 to requirement estimates and then use the Forecast tool based on a count of work items.

Best practice tips:

  • Periodically refine your backlog
  • Make sure features and requirements are sized appropriately
  • Define the acceptance criteria and the definition of done for features and work
  • Map unmapped work to Features
  • Forecast your backlog

To learn how:

Use tags to support queries and filtering

With work item tags, team members can assign ad-hoc tags to work items. You can use these tags to filter backlogs and boards as well as query on work items. For tags to be useful to the team, provide some general guidance on how your team should use tags. Consider documenting this guidance in a central place, such as the project wiki.

The following image illustrates a Kanban board filtered on the web keyword which displays cards with the Web tag.

Screenshot of Kanban board, Filter using keyword search.

Best practice tips:

  • Have a policy in place about how your teams will use tags
  • Indicate how you'll use tags to support queries, filtering, reporting
  • Consider using tags to identify cross-team or cross-project dependencies

To learn how:

Forecast and milestone planning

To gain insight into what features can ship when, use the Forecast tool. This tool requires that you provide estimates to the Story Points, Effort, or Size field for each requirement. If you want to forecast on a simple count of work items, then simply assign the value of 1 to requirement estimates.

Order the features backlog in priority order

As project managers, you'll want to always have your features backlog in priority order. This conveys to the development team which features are most important to complete first.

Here the features backlog shows the sequence of features to ship.

Screenshot of Features backlog, ordered by feature parent.

Order the requirements backlog based on parent features

First you want to make sure you are completing the requirements needed to ship features. As shown in the following image, the requirements backlog has been ordered according to the features you want to ship. This ordering assumes that all requirements in a feature must be complete in order to ship it. Also, Story Points have been assigned to each User Story.

Screenshot of Requirements backlog, ordered by feature parent.

Forecast the requirements backlog

With estimates assigned to each requirement, you can set a team velocity. In the example below, we specify 12 for the velocity, equivalent to stating that on average the team can complete 12 Story Points per sprint. The Forecast tool shows which requirements and features the team can complete within the next six sprints. Using the Planning tool, you can quickly assign requirements to the forecasted sprints.

To see the full image, click the image to expand. Choose the close icon close icon to close.

Screenshot of Forecast of Requirements backlog, ordered by feature parent.

Getting good at estimates and having predictable team velocities are useful team goals for process improvement.

Update your Features board

With a forecast of when a feature will ship, you can update each feature's iteration path. Quickly assign values to a feature by adding those fields to the card on the Kanban board as shown in the following image.

Screenshot of Features board with updated iteration paths.

Milestone planning

Milestone markers aren't used in Azure Boards work tracking, except for Delivery Plans. Delivery Plans provide a calendar view and allow you to define a milestone marker. However, you can use one or more of the following options to mark a work item as a milestone:

Manage dependencies

In Microsoft Project, you manage tasks that depend on the completion of other tasks by linking them. To manage dependencies in Azure Boards, you can add similar linking by adding Predecessor/Successor link types to work items. You add these links from the Add link dialog for a work item.

Azure Boards supports a number of link types to track related work. Choose the Predecessor/Successor link types to track work with dependencies. The quickest way to add a number of these links is to add a tag to work items that participate in producing or consuming dependencies, create a query based on this tag, and then add the required links from the triage mode of the query results.

The following Add link dialog illustrates how two work items are linked using the Successor link type.

Screenshot of Add link dialog, successor link type.

Visualize work item relationships

With the Work Item Visualization Marketplace extension, you can visualize the link relationships among several work items as shown in the following image.

To see the full image, click the image to expand. Choose the close icon close icon to close.

Screenshot of Visualize work item relationships.

Minimum Viable Product versus Critical Path Management

Azure Boards doesn't provide a native view of the critical path. In part, as Agile methodologies favor a Minimum Viable Product (MVP) over Critical Path Management (CPM). By using MVP, you identify the shortest path and dependencies by prioritizing epics, features, stories and tasks. For additional context, see The Critical Path on Agile Projects and Running a lean startup on Azure DevOps.

Best practice tips:

  • Add a dependency tag to work items participating in dependency management
  • Use Predecessor/Successor link types to track dependencies of work owned by other teams or within other projects
  • Create queries to track, add, and triage dependencies
  • Use the Dependency Tracker Marketplace extension to view work that you have dependencies on from other teams
  • Use the Work Item Visualization Marketplace extension to visualize dependencies

Note

Marketplace extensions are not supported features of Azure Boards and therefore not supported by the product team. For questions, suggestions, or issues you have when using these extensions, visit their corresponding extension page.

To learn how:

Work in sprints

Sprints allow the development team to focus on completing a pre-selected set of work. Work assign to a sprint appears on the team's sprint backlog. Sprint backlogs are defined only for product backlogs, not for portfolio backlogs.

Sprint burndown chart

By updating the status of work daily throughout a sprint, you can easily track sprint progress with the Sprint burndown chart, as shown in the following image.

Screenshot of Analytics Sprint burndown chart.

Best practice tips

Each sprint, perform the following tasks:

  • Plan each sprint with your team
  • Use the team's Sprint backlog to review sprint deliverables
  • Ensure each sprint work item is assigned to a team member
  • Ensure each work item is scoped to be completed within the sprint
  • Ensure the acceptance criteria for the work is well defined and understood
  • Update the status of sprint work items as work moves from a New to Active to Completed state to track sprint burndown
  • Check in with other teams on dependencies that your team's work depends on
  • Monitor sprint progress using the Sprint burndown chart

To learn how:

Review progress and feature deliverables

The three main tools you'll want to use to review progress and deliverables are:

  • Features Kanban board
  • Features backlog with rollup columns
  • Delivery plans

Features Kanban board

Your Features board is another place to review progress and ensure the continuous flow of deliverables. The following image illustrates a customized Features board. In progress columns have been added such as Need more info, Spec Complete, In Progress, and Customer Rollout. These provide a more natural set of states as Features get proposed, researched, designed, developed, and then deployed to production.

To see the full image, click the image to expand. Choose the close icon close icon to close.

Screenshot of Features board with customized columns.

Rollup

One quick and visual way to monitor progress is from the Features backlog. By adding the rollup progress bar column, you can see what percentage of work items are completed for each feature, as shown in the following image.

Screenshot of Features backlog showing progress bars column option.

Delivery plans and multiple team deliverables

To review features delivered across several teams, configure a delivery plan. Delivery plans provide an interactive board to review a calendar schedule of stories or features several teams plan to deliver.

Interactive plan elements ### Best practice tips
  • Customize your Features Kanban board to support your team's processes
  • Add fields to cards so that you can update their values quickly and easily
  • Update the Iteration Path (Sprint) of Features as you gain clarity as to when they will ship
  • Review the Features board to talk through status, blocks/issues/risks/changes,and update status
  • Use the filter feature to focus on tagged items, assigned by features, a specific sprint and more
  • Add rollup columns to your Feature backlog to monitor overall progress based on work item count completion
  • Use delivery plans to review features being delivered by several teams and discuss cross-team dependencies

To learn how:

Process improvement

At the heart of Agile methods is continuous improvement. To improve your processes, you need to have shared goals and a shared plan. To initiate process improvement activities, consider adding them through regular practices, such as:

  • Sprint planning
  • Setting sprint goals
  • Conducting regular retrospectives

Consider the following questions when setting goals:

  • What are you learning about your customers? What do you need to know?
  • What data is being measured? Is it actionable? What data needs to be measured?
  • How is the flow of deliverables? Is it as expected? Where can improvements be made?
  • Are your team members empowered to do their best? What tools or information would help them improve?
  • How well is information being shared? How well are teams collaborating?
  • How well is your team managing technical debt and closing bugs?

Some of the Agile tools you can use to support process improvement are team velocity, team dashboards, and the Retrospectives Marketplace extension.

Team velocity

From the team velocity chart, you can gain an understanding as to how well the team is planning and executing a sprint. As shown in the following example, the velocity chart shows the planned, completed, completed late, and incomplete count of work items for several sprints. Teams can review this chart to help determine how well they are estimating and executing and how they might improve.

Screenshot of Example team velocity chart.

Team dashboards

Teams can define one or more dashboards to share information and monitor real-time data on work progress.

Screenshot of Example team dashboard.

Best practice tips

  • Identify process improvement goals that your team can agree to, write them down and review them periodically
  • Use team dashboards to share information and work tracking charts which you and your team review periodically
  • At sprint planning meetings, have your team identify at least one sprint goal related to process improvement
  • Conduct regular retrospectives to capture what went well, what didn't go well, and actions to improve
  • Maintain an improvement tracking board, such as that available with the Retrospectives Marketplace extension.

To learn how:

Try this next

Configure and customize Azure Boards

Industry articles