Azure DevOps: How to tell what was planned in a sprint? - azure-devops

Yes I can see what is currently in the sprint, but how can I tell what was originally planned in a sprint?
I would like to be able to query this for a chart on my dashboard. Additionally, I want to be able to pass this information over to Power Bi via Analytics View.

Usually, we create product backlog to correspond to your project plan, the roadmap for what your team plans to deliver. You create your product backlog by adding Issues (Basic process), User Stories (Agile), Product Backlog Items (Scrum), Requirements (CMMI).
Your backlog consists of a list of work items. You use work items to share information, assign work to team members, track dependencies, organize work, and more.
If you want to track your project plan, you should query your product backlog.
https://learn.microsoft.com/en-us/azure/devops/report/powerbi/create-quick-report?view=azure-devops

Related

What work item to select in Azure Devops Server (TFS)

I'm fairly new to the different work items available in Azure Devops Server 2020 (TFS) and wonder if I could get some advice on what to select.
I am the only developer in a project and have direct contact with the stakeholder. When the stakeholder report an issue should I then create an Issue/impediment that describes whats is wrong or needs to be changed. And then create a task or bug that I link to that issue/impediment?
You can use Agile Glossary to get some information.
Issues/Impediments:
A type of work item that helps track unplanned activities. Resolving
an issue or impediment requires more work beyond what was scheduled
based on actual requirements.
Bugs:
A type of work item that records a potential source of dissatisfaction
with the product.
You can use Bugs to report issues from your stakeholders and here you also use two ways:
Use bugs on the requirements level and create tasks under it.
Use bugs on tasks level and link them to affected user story or product backlog item.
Show bugs on backlogs and boards
Or you can use user stories/product backlog items as a record to enhance your product.

Features spanning multiple sprints in Azure Devops

I'm trying to organize the work for my team in Azure Devops and have started to break down my work into the work item types provided: Epics, Features and Backlog Items. My understanding is that the Features are a collection of related stories that don't necessarily fit into a single sprint, that is they are a portfolio management thing (a folder).
When I create a Plan I can choose to display Features, but I can only have a feature assigned to a single sprint at any one time. How can I get features showing in a Plan across multiple sprints?
I'm not sure there's a "right" way to do this, but I personally would assign Features to the last sprint in which all User Stories will be delivered. Likewise I would do the same between Epics and Features.
Features and Epics are expected to be completed over multiple sprints, so the notion of using a sprint assignment to show when they're going to be "worked on" (like a User Story) is really replaced by when all components of that feature will be delivered. That's how I'm using them anyway.
If you set the start and end dates of the feature, it will span across multiple sprints.

Sprint Burndown/Burnups in Azure Devops

I need a sprint burndown chart on our dashboard in Azure Devops, but none of the available seem to fit my needs.
The burndown should reflect number of tasks, bugs and User Stories in the sprint, but the ones described here do not fulfill those needs. They either require hour estimates on each task/bug, or can give a count of one of the above Item types (Task, Bug or User Story) at a time. The "Sprint Burndown (Legacy) widget" is what comes closest to my needs, only that it does not show the burndown from Sprint start, and does not have an ideal trend line, which I would also like.
Moreover, a burnup chart would also be nice to have, but again nothing satisfies that.
The widgets provided in the dashboard are all designed. As the document stated: You can define remaining work based on Stories or Tasks, and by counting the work items or summing a field. So if you want to react to the count of tasks, bugs and stories in a Sprint Burn down widget, it is currently not possible. You could submit a feature request in our Develop Community site to promote development of richer features.
With the burndown widget, you can display the number of stories and bugs together. Because this widget has Include bugs on the Stories backlog option. If you select the Stories backlog you are presented with this additional option. Place a checkmark in the box to include bugs along with user stories in your burndown. But this also can't display the count of tasks together.
If you want to reflect the number of these items , you can choose to add a few more widgets. Or as Mar Tin said in the comment, you can develop a custom widget.
Update:
With queries you can list the work items of interest (items in the Requirements category or estimated, remaining, and completed work for items in the Task category), and then define a chart that shows either a count of work items or a sum of a numeric field.
Then create a chart based on this query and add to dashboard.
For details,please refer to documents: Remaining and completed work queries and charts; Create work tracking charts

Azure DevOps hide developers list to stakeholders

I'd like to avoid for the stakeholders to view the name of developers working on tasks (Assigned To columns).
Is there a way to hide it?
Unfortunately, there isn't a permission model for fields in a Process Template, so it isn't possible to hide the field only for certain users.
There are a few places in the user-interface where you can customize the view. For example, you can customize the settings for the Kanban Board to pick and choose which fields are displayed:
And while you can remove Columns from lists, this is only a band-aid workaround as the information is still available and columns can easily be added back in for personal views.
In an agile world, we want our stakeholders to have visibility. Microsoft's view of DevOps is "people and process working with tools to deliver value to customers". Stakeholders have a role in your project, but their contributions aren't the same as those that are doing the work. The classic example is Ham and Eggs
If your concerns are truly about privacy - don't give Stakeholders access! Consider finding an alternate method of keeping them in the loop. For example, Azure DevOps allows you to query their system via an Excel Plugin.

Team Services team's backlog not showing tasks

I'm currently using Team Services with multiple teams but am having an issue with displaying tasks on the specific team's backlog.
I have created two teams (Portal & Core) with there own area.
I have created a story and have set it to the root area.
To complete this story requires effort by both teams. I have created a task for the Portal team and set it to their area and another task for the Core team and have set it to their area.
If I look at the teams backlog I cannot see the task for them (I have set Show Parents).
Should I be able to split tasks of a story across multiple teams?
Thanks
No, there isn't any way to achieve this directly. But there is an alternative method for this, refer to the steps below for details:
Go to the "Work\Area" settings of the root project and add a new child area for example "TwoTeams".
Go to the "Work\Area" settings of the child projects(Portal & Core) and add "CrossTeam\TwoTeams" area to them.
Assign the user story to "CrossTeam\TwoTeams" area.
Now you will see the User Story and Tasks on the teams backlog like following:
Whether you should be able to is one thing, which is a broader topic. Whether you can is a different question, one with an exact, factual answer: You can't.
A user story is intended to be a discrete unit of work that is completed by a single cross-functional team. If you have multiple teams working on one user story, chances are good that the user story is too large and should be decomposed further.