Get started as a Stakeholder

TFS 2017 | TFS 2015 | TFS 2013

Stakeholders are users with free but limited access to Azure DevOps features and functions. With Stakeholder access, you can add and modify work items. You can check project status and provide direction, feedback, feature ideas, and business alignment to a team.

Stakeholder access is one of several supported access levels as described in Stakeholder access quick reference. To get access as a Stakeholder, ask your server administrator to add you to a security group that has Stakeholder access.

Note

Azure Boards supports several Agile methods such as Kanban and Scrum. Depending on what methods your team uses, you'll want to become familiar with other tools that Azure Boards supports. This article focuses on getting familiar with work items and the Kanban board. For additional information, see Related articles at the end of this article.

Use this tutorial to learn how to do the following tasks:

• Sign in to a project
• Understand which work item types are available to your project
• Open the Kanban board and open a work item
• Add details, tags, or comments to a work item
• View the product backlog
• Find work assigned to you, or query for other work items
• Understand what features are and aren't available to users with Stakeholder access

Connect to the web portal of a project

You must have been added to the Azure DevOps project and been granted Stakeholder or higher access level.

1. Choose the link provided in the email invitation you should have received. Or, open a browser window and enter the URL for the web portal.

   http://ServerName:8080/tfs/DefaultCollection/ProjectName For example, to connect to the server named FabrikamPrime and project named Contoso, enter http://FabrikamPrime:8080/tfs/DefaultCollection/Contoso.

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 work item types

Work items support planning and tracking work. Each work item represents an object stored in the work item data store. 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 to you 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. To learn more 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.

To learn more 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. To learn more 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. To learn more about using these work item types, see CMMI process.

Open your Kanban board from the web portal

You can start viewing work items once you connect to a project.

1. To view your Kanban board, open your project from a web browser. Select Work > Backlogs > Stories, and then select Board.

   

   If you don't see Work, your screen size might be reduced. Select the three dots ( ) icon. Then select Work > Backlogs > Board.

   

2. To select another team, open the project and team selector. Select a different team, or select the Browse option.

   

   Your Kanban board appears.

   

Add work items

From the Kanban board, you can't add work items, but you can open them and annotate them. To add work items, open the backlog by choosing the Backlog link. Also, you can't update the status of a work item by drag-and-drop to a different column or reorder cards within a column.

Add details to a work item

To add information to a work item, open it by double-clicking the title or by selecting it and then typing Enter. Add a description, change one or more field values, or add a tag. You can also choose the Attachments tab and upload a file to the work item to share with others.

You can only assign work to a user who has been added to the project.

Note

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

Agile process

For example, here we assign the story to Raisa Pokrovskaya and we add a discussion note, at-mentioning Raisa. Choose Save & Close when done.

Basic process

For example, here we assign the issue to Raisa Pokrovskaya and we add a discussion note, at-mentioning Raisa. Choose Save & Close when done.

Scrum process

For example, here we assign the Product Backlog Item to Jamal Hartnett and add a description and tags. Choose Save & Close when done.

CMMI process

For example, here we assign the Requirement to Jamal Hartnett. Choose Save & Close when done.

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.

---

Field descriptions

---

Field

Usage

---

Title

Enter a description of 255 characters or less. You can always modify the title later.

---

Assigned To

Assign the work item to the team member responsible for performing the work. Depending on the context you are working in, the drop-down menu lists only team members or contributors to the project.

Note

You can only assign work to a single user. If you need to assign work to more than one user, add a work item for each user and distinguish the work to be done by title and description. The Assigned To field only accepts user accounts that have been added to a project or team.

---

State

When the work item is created, the State defaults to the first state in the workflow. As work progresses, update it to reflect the current status.

---

Reason

Use the default first. Update it when you change state as need. Each State is associated with a default reason.

---

Area (Path)

Choose the area path associated with the product or team, or leave blank until assigned during a planning meeting. To change the dropdown list of areas, see Define area paths and assign to a team.

---

Iteration (Path)

Choose the sprint or iteration in which the work is to be completed, or leave it blank and assign it later during a planning meeting. To change the drop-down list of iterations, see Define iteration paths and configure team iterations.

---

Description

Provide enough detail to create shared understanding of scope and support estimation efforts. Focus on the user, what they want to accomplish, and why. Don't describe how to develop the product. Do provide sufficient details so that your team can write tasks and test cases to implement the item.

---

Acceptance Criteria

Provide the criteria to be met before the work item can be closed. Define what "Done" means by describing the criteria for the team to use to verify whether the backlog item or bug fix is fully implemented. Before work begins, describe the criteria for customer acceptance as clearly as possible. Have conversations between the team and customers to determine the acceptance criteria. These criteria help ensure a common understanding within the team to meet customers' expectations. Also, this information provides the basis for acceptance testing.

---

Priority

A subjective rating of the issue or task it relates to the business. You can specify the following values:

• 1: Product cannot ship without the successful resolution of the work item, and it should be addressed as soon as possible.
• 2: Product cannot ship without the successful resolution of the work item, but it does not need to be addressed immediately.
• 3: Resolution of the work item is optional based on resources, time, and risk.
• 4: Resolution of the work item is not required.

---

Value Area

A subjective rating of the issue or task it relates to the business. You can specify the following values:

• Architectural: Technical services to implement business features that deliver solution .
• Business: Services that fulfill customers or stakeholder needs that directly deliver customer value to support the business (Default).

---

Effort, Story Points, Size

Provide a relative estimate of the amount of work required to complete an issue. Most Agile methods recommend that you set estimates for backlog items based on relative size of work. Such methods include powers of 2 (1, 2, 4, 8) and the Fibonacci sequence (1, 2, 3, 5, 8, etc.). Use any numeric unit of measurement your team prefers.
The estimates you set are used to calculate team velocity and forecast sprints.

---

Add tags to a work item

Tags are useful for filtering backlogs, boards, and queries. As a Stakeholder, you can add existing tags to a work item, however, you can't add new tags.

From the web portal, open a work item and choose Add tag and type a keyword of an existing tag. Or, select from the list of previously assigned tags.

Tags that appear in the tag bar are already assigned to the work item. To unassign a tag, choose the x on the tag,.

Check the backlog and prioritized work

You can check the product backlog to see how the team has prioritized work. Backlog items appear in priority order. Work item types may include bugs depending on the settings made for the team.

From the Kanban board, choose Backlog.

You should see the list of backlog items listed in priority order. You can add a backlog item which will be placed at the bottom of the list. With Stakeholder access, you can't re-prioritize work.

To view or edit a work item, select it and choose Enter.

Find work assigned to you, or query for other work items

1. Open Work>Queries and select Assigned to me to see the list of work items assigned to you.

   

2. Or, open any of the queries defined in the Shared Queries folder.

   

3. And, you can create new queries or edit existing queries and save them under My Queries folder.

   

Related articles

For a comparison chart of Stakeholder versus Basic access, see this feature matrix. See also these quickstart guides:

• Add work items
• Create your backlog
• Kanban quickstart
• Access levels
• Change access levels