Get started as a Stakeholder

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Stakeholders are users with free but limited access to Azure DevOps features and functions. With Stakeholder access, you can add and modify work items, manage build and release pipelines, and view dashboards. You can check project status and provide direction, feedback, feature ideas, and business alignment to a team. For information about working with pipelines, see Build your GitHub repository and Build OSS repositories.

For more information, see the Stakeholder access quick reference. To compare Stakeholder versus Basic access, see the feature matrix.

In this tutorial, learn how to:

• Understand Stakeholder access and available features
• Sign in to a project
• Understand work items and types
• Open your Kanban board
• Add work items
• Update work items
• View the backlog
• Find work items

Prerequisites

• You must have Stakeholder access for a private project and be a member of the Contributors or Project Administrators group. You can view boards, open and modify work items, and add child tasks to a checklist. But, you can't reorder or reparent a backlog item using drag-and-drop, nor update a field on a card.
• You must have Stakeholder access for a public project and be a member of the Contributors or Project Administrators group to have full access to all Boards features. For more information, see Default roles and access for public projects

To get access as a Stakeholder, ask your organization owner or Project Collection Administrator to add you to a project with Stakeholder access.

Sign in to a project

1. Select the link provided in your email invitation or open a browser window and enter the URL for the web portal.

   https://dev.azure.com/OrganizationName/ProjectName

2. Enter your credentials. If you can't sign in, ask the organization owner or Project Administrator to add you as a member of the project with Stakeholder access.

Understand work items and types

Work items support planning and tracking work. Each work item is based on a work item type and is assigned an identifier, which is unique within an organization or project collection.

Different work items are used to track different types of work, as described in About work items. The work item types available are based on the process used when your project was created—Agile, Basic, Scrum, or CMMI—as illustrated in the following images.

Agile process

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.

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

Basic process

The following image shows the Basic process backlog work item hierarchy. Issues and Tasks are used to track work, while Epics are used to group work under larger scenarios. The Basic process is available with Azure DevOps Server 2019 Update 1 and later versions.

For more information about using these work item types, see Plan and track work.

Scrum process

The following image shows the Scrum process backlog work item hierarchy. Product Backlog Items and Tasks are used to track work, Bugs track code defects, and Epics and Features are used to group work under larger scenarios.

Each team can configure how they manage bugs—at the same level as Product Backlog Items or Tasks—by configuring the Working with bugs setting. For more information about using these work item types, see Scrum process.

CMMI process

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

Each team can configure how they manage bugs—at the same level as Requirements or Tasks—by configuring the Working with bugs setting. For more information about using these work item types, see CMMI process.

Open your Kanban board

You can view work items once you connect to a project.

1. In your project, and select Boards > Boards, and then select a team board from the dropdown menu.

   

   You can also enter a keyword in the search box or select View Board directory to see a list of available team boards.

   

   Tip

   Select the star icon to make a team board a favorite. Favorite artifacts ( favorite icon) appear at the top of the team selector list.

2. Check that you selected Stories for Agile, Issues for Basic, Backlog items for Scrum, or Requirements for CMMI as the backlog level.

   

Add work items

From your board, select the plus sign, enter a title, and then select Enter.

For more information, see View and add work items from the Work Items page.

Update work items

The work item forms you see may differ from the following images. The basic functionality is the same, however, changes have been made with different versions of Azure DevOps.

Change status

Drag and drop a work item to move it downstream as you complete work.

Add details

To open a work item, double-click the title or highlight it, and then select Enter. Here we show how to assign work. You can only assign work to a user who is added to the project.

Agile process

For example, here we assign the story to Raisa Pokrovskaya and we add a discussion note, at-mentioning Raisa. When you're done, select Save & Close.

Basic process

For example, here we assign the issue to Raisa Pokrovskaya and we add a discussion note, at-mentioning Raisa. When you're done, select Save & Close.

Scrum process

For example, here we assign the Product Backlog Item to Jamal Hartnett and add a description and tags. When you're done, select Save & Close.

CMMI process

For example, here we assign the Requirement to Jamal Hartnett. When you're done, select Save & Close.

CMMI-specific field descriptions

---

Field

Definition

---

Impact Assessment

The customer impact of not implementing this requirement. You might include details from the Kano model about whether this requirement is in the surprise, required, or obvious categories. You capture this information in the rich-text HTML field which corresponds to Impact Assessment.

---

Requirement Type(Required)

The kind of requirement to implement. You can specify one of the following values:

• Business Objective
• Feature
• Functional
• Interface
• Operational
• Quality of Service
• Safety
• Scenario
• Security

---

Start Date/Finish Date

The target dates for when the work will start or finish. These fields are filled in by Microsoft Project when you use it for scheduling.
You can specify work in hours or in days. There are no inherent time units associated with this field.

---

Triage (Required)

Indicates the type of triage decision that is pending for the work item. Use this field when the work item is in the Proposed state and specify one of the following values: Pending (default), More Info, Info Received, or Triaged.

---

Blocked

Indicates whether a team member is prevented from making progress toward implementing a requirement or task or resolving a bug, change request, or risk. If an issue has been opened to track a blocking problem, you can create a link to the issue. You can specify Yes or No (default).

---

Committed (Required)

Indicates whether the requirement is committed in the project or not. You can specify Yes or No (default).

---

Integrated In

Product build number that incorporates the requirement, change request, or fixes a bug.

---

User Acceptance Test (Required)

The status of the user acceptance test for a requirement. You can specify one of the following values:

• Pass
• Fail
• Not Ready
• Ready
• Skipped
• Info Received
  Specify Not Ready when the requirement is in the Active state, and you specify Ready when the requirement is in the Resolved state.

---

Subject Matter Experts

The names of team members who are familiar with the customer area that this requirement represents.

---

Add more details by changing field values, adding a description or tags, and adding comments. For more information, see the following articles:

• Update fields: Descriptions and usage
• Add tags to work items. As a Stakeholder, you can add existing tags to a work item, but you can't add new tags.
• Capture comments in the Discussion section

View as Backlog

Check the product backlog to see how the team prioritized their work. Backlog items appear in priority order. Work item types may include bugs depending on the process used when your project was created.

From the Kanban board, choose View as Backlog.

You should see the list of backlog items listed in priority order. You can add a backlog item, which goes to the bottom of the list. With Stakeholder access, you can't reprioritize work.

Find work items

Choose Boards > Work Items > and then select an option from the dropdown menu. Here we chose Assigned to me.

For more information, see the following articles:

• View, run, or email a work item query
• View and add work items using the Work Items page

Next steps

Create your product backlog

Related articles

• Add work items
• Kanban quickstart
• Access levels
• Change access levels