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, view and approve pipelines, and view dashboards. 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.
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/ProjectNameFor example, to connect to the server named FabrikamPrime and project named Contoso, enterhttp://FabrikamPrime:8080/tfs/DefaultCollection/Contoso.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.
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.
Open your Kanban board from the web portal
You can start viewing work items once you connect to a project.
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.
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. Change one or more field values, add a description, add a tag, or add a comment in the Discussion section. You can also choose the 
Attachments tab and drag-and-drop or upload a file 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.
For example, here we assign the story to Raisa Pokrovskaya and we add a discussion note, at-mentioning Raisa. Choose Save & Close when done.
Field descriptions
Field
Usage
Enter a description of 255 characters or less. You can always modify the title later.
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.
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.
Use the default first. Update it when you change state as need. Each State is associated with a default reason.
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.
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.
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.
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.
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.
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).
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,
.
Capture comments in the Discussion section
Use the Discussion section to add and review comments made about the work being performed.
Use the @mention control to notify another team member about the discussion. Simply type @ and their name. To reference a work item, use the #ID control. Type # and a list of work items that you've recently referenced will appear from which you can select.
To reference a work item, use the #ID control. Type # and a list of work items that you've recently referenced will appear from which you can select.
You can't edit or delete comments once you've entered them.
Important
For on-premises Azure DevOps Server, you must configure an SMTP server in order for team members to receive notifications.
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
Open Work>Queries and select Assigned to me to see the list of work items assigned to you.
Or, open any of the queries defined in the Shared Queries folder.
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: