We're using Azure Devops Boards as our primary work tracking environment. For our agile planning process, we've got a backlog full of user stories for which we use tags to categorize PBIs. For instance, when a story is ready for refinement by the team, it's tagged with Refinement. As soon as refinement is done it's tagged with Ready to indicate we're going to take it up for sprint planning. Nothing out of the ordinary I'd say.
Now I was looking for a way to historically chart the count of user stories having these tags, but I can't seem to find a widget supporting that. The time-tracking widgets don't seem to take tags into account and with the query-type widgets you can search for tags but you get the current set of items, not the option to plot it historically.
Does anyone know whether this can be done in one way or the other?
Some fields have a was ever such as State. Tags don't appear to support a was ever operator though, so you may have to use the REST API to search the audit data. https://learn.microsoft.com/en-us/rest/api/azure/devops/audit/?view=azure-devops-rest-6.0
Related
I'm curious with usage of DevOps boards/sprints/kanban, what is the industry standard for handling usage by multiple stakeholders?
More specifically, DevOps comes with standard states like "Active/Resolved/etc", but what if we want to capture more, such as "Deployed to env X", or even testing statuses. I know we can add additional statuses, but is that the right thing to do?
The challenge we have, is if the Kanban is used, then all those statuses must be represented on the Kanban, because movement on that board actually sets the status, so if we remove a status column from the Kanban, any WI with that status would effectively be hidden.
So effectively, I've added a bunch of statuses to cater for environments, testing, different reasons for on-hold, etc, but its being argued that this makes the Kanban too complex to get an easy snapshot of whats happening.
It's been suggested that we remove all these statuses, and instead use Tags and Swimlanes, which seems much less robust to me, it accomplishes the same thing, but without a single source of truth like the status provides.
Just curious if anyone with more experience with DevOps can shed light on how they've tackled this.
It looks that you want to get feature which is not implemented - Allow multiple states in the KanBan Board Columns
Actually the TFS allows only one state for every column in the KanBan Board which makes the whole developing process messy. We had to create several columns for all the states that our dev team has. It would be great if TFS could allow to assign multiple states to the columns, and doing and done columns to reduce the number of columns in the whole process.
There is no way to overcome this and what you need.
You can create custom field with pick list and then configure Kanban to display this field on the board:
This maybe helps you a bit.
We are using Azure DevOps to track our development work. I can open an individual story and see the history of changes and the chart of the status history. This is useful for an individual story, but doesn't allow me to identify trends and possibly highlight issues in our processes.
I would like to have a chart, or an export that shows the historical changes for all stories (within a date range, or some other filter) so I can discover:
How long does a story stay in each status, on average? (Q: Which statuses take the most time)
How many times is a story set to a status, on average? (Q: When and how often are we moving backward in the flow)
How many times does a story move backward for each team member? (Q: Where should we focus our training efforts)
I have searched within the dashboard, reports, and online for some way to get this information and either haven't used the right keywords, it doesn't exist, or I totally missed it.
Does anyone know if this type of information is available and how I can access it?
There isn't an easy way to accomplish this, unfortunately. Your best bet is going to be composing a Power BI report or Excel, whichever you're most familiar with. Even then, you're going to run into problems with #2 and #3. Microsoft doesn't have an easily accessible way to query the history of each status among all work items.
However, #1 is possible within PowerBI and Excel. Here are a few guides to get you started:
Excel
To import Queries into excel, you have to install a few things follow this guide to get started:
https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/office/track-work?view=azure-devops&tabs=open-excel
Power BI
To get started consuming Analytics views within Power BI, follow this guide:
https://learn.microsoft.com/en-us/azure/devops/report/powerbi/create-quick-report?view=azure-devops
Whether you're using PowerBI or Excel, the fields you'll want to include within your query or Analytics View will look like "[STATUS] Date", "Closed Date" for example. That will make them accessible within PowerBI, or Excel, depending on which you go with.
Once you have your data, you'll want to create reports that compare the status dates to determine how long a story stays within a status.
Azure DevOps Report for User Story Status History
Azure devops is not intended to be a time tracking tool. You could query the work item history with the TFS API and check the timestamps on when the state transitions occurred if you really wanted to.
So, Azure devops doesn't track the time spent on a per day basis. It keeps track of the total time spent. If you want a per person per day value, you'll have to go through the iterations/workitem history and calculate the running difference.
If you really looking for a TimeReporting for the work items of per person, I suggest that you take a look at a third party yool like Timetracker:
Timetracker
New to version 5.0.! Individual, team, and custom reports powered by
version 3 of the REST-based reporting API. 7+ customizable widget
types that let you see data that you need, how you need it. In
addition to the six default reports in Reporting, users can create
custom reports for individuals or teams.
On the other hand, we could develop our scripts via REST API Revisions - List to get the System.State change and System.ChangedDate, then compare the date to get the time in each status.
Our company has recently introduced Azure DevOps to streamline project management process. Currently, 140 projects are created under our organization in Azure DevOps. As and when requirement comes from client for any specific project, we create tasks/bugs for different developers under that project. Currently we use only two Work Item type - Bug and Task.
Now the issue is Management of the company wants to see Project-wise number of "New/Open", "Active" and "Closed" Tasks and Bugs in a SINGLE chart. That means, that single chart must fit consolidated data of 140 projects. If a person views that single chart they must get idea, for example that - Project 1 has 2 new/open work items, 2 active work items and 2 closed Work items , Project 2 has 1 new/open work items, 10 active work items and 3 closed Work items and so on.. This is done so that management in a glance can understand which project is lagging behind for customer delivery. So that they can work accordingly build more manpower for those Projects.
I have tried to create various such charts and widgets with different queries in Azure DevOps. I used widget burn up and burn out charts but it gives data for tasks of single Project only. Also when we add multiple projects to it, it shows summation of completed/remaining tasks for those Projects & NOT Project name-wise completed/remaining tasks bifurcation.
I also tried "Charts for work item" widget but it also fetches count as per- Assignee, State and Work Item type and not project name wise count is fetched.
I don't want to navigate through 140 projects pages to see it's open, active and closed tasks. So please help me out in suggesting the ideas on How can I build a single chart from where we can get all this data? I will be forever grateful for your answers.
Thank you!
You could create a query across projects, select Team Project column in Column option, ad save the query as shared query. Check the screenshots below:
Then add a chart widget to a dashboard, select Pivot table, and set Team Projects, State as Rows and Columns. Check the screenshot below:
You could expand the view to see more details:
https://learn.microsoft.com/en-us/azure/devops/report/dashboards/charts?view=azure-devops#add-a-chart-widget-to-a-dashboard
I'd be slightly careful based on what you've put down because I don't think your management team quite understand what they need, and DevOps can only do so much. I'd be challenging them around the setup of your DevOps process personally because I don't think it's advisable to not have user stories as part of your setup. Although it simplifies some aspects of DevOps, our experience has been that people have been able to group things together better with user stories as well as tasks.
Appreciate it's a good idea to be able to see what's going on across all projects, but I think there are probably further criteria to think about. E.g. do you want to see estimates instead of/as well as the count of the items since that will have a better reflection of the effort required. In terms of completed items and in fact, probably all that you're displaying, again it's more on your project process, but are management genuinely interested in everything? For example, do they need to know that something was closed 6 months ago, or are they just interested in the last month?
I suppose what I'm getting at is you probably need a bit more information from management about what they want to use the report for so you can give them what they need rather than they want. There's a temptation to say you want everything because you don't understand the capabilities of the solution or what you're going to use it for, and my recommendation would be to challenge them on this so you can better present things (giving them what they need rather than what they want).
In terms of what you're looking to do, I'll openly admit I'm not clued up on everything DevOps related but I doubt you'll be able to report at a project level within DevOps. I think what you'd need to do is set up your query, which would look across all projects in your organisation, and then export the results to Excel. From there I'd create a pivot table (or perhaps more than 1) with the data that you need. Have Project names down the left side (row headers), and bring in whatever else you need as columns. I think that's probably a good quick win to get something in front of your management team, and then you could challenge from there - almost picking holes in it so that they realise that the business decisions that they'd make from this may not be fully informed, and suggesting some changes. From experience, it's probably better to consider it almost as a prototype and not get bogged down with a solution at this stage because you may be asked for changes when they can visualise what they've originally asked for. Once management is happy you could look at other solutions to provide the report, but Excel is typically a good starting point I've found in the past when working on something new like this.
In Microsoft's VSTS, is there a way to have User Story as a child of Epic in the Agile process template, eg including when performing "mapping", without creating a VSTS custom process template? In the image below in the main content area, hide / remove Feature, and in the "Mapping" panel on the right, have Epics for mapping User Stories.
I'm asking because in my org's agile practice we have epics and user stories but we don't see the need / benefit to the extra layer of Feature WIT.
OOTB Agile process template has Epic > Feature > User Story and when you view Product Backlog (aka user stories) you can map them to Features and when you view Feature portfolio backlog you can map them to Epics, but you can't (that I know of) turn off the Feature WIT so that User Stories can be mapped directly to Epics in the GUI.
Btw, it isn't possible to rename OOTB WITs otherwise I would simply turn off Epic WIT and rename it to "Epic OOTB", and rename Feature WIT to "Epic My Org".
UPDATE: Per Add a portfolio backlog level it is possible to add a portfolio backlog level with a new WIT:
You'll first export your process, add or update definition files, and
then import that process to either update existing team projects or
use it to create a team project.
but I want to remove one. I may try the reverse using this procedure but first I'd like some reassurance that it likely works for removing an OOTB level.
Some of the docs I've consulted include:
Agile process work item types and workflow - Microsoft Docs
Define features and epics - Microsoft Docs
There isn’t such feature in VSTS, also you can’t custom too: Modify the backlog and boards
Why don't you use tools like Jira or Rally to map in your agile practices? It will be immensely beneficial in long run.
Agile, by its very definition, means that you should be flexible. As such, ignoring the User Story as a sub-class of feature can be done. However, I think that if the focus of your delivery has a strong user-component to it, then marrying that up in deliverables will give a better indicator to your product owners.
If you're scrumming it, then you'd generally be working on a feature-task loop anyway, so I wouldn't worry, VSTS seems to cope well with both.
VSTS doesn't really concentrate heavy on Workflows OOTB like JIRA pushes (I've seen some crazy JIRA workflows in my time), although it is quite extensible, I believe the VSTS Team have gone Zen Agile in terms of offering a service that helps teams develop code first and foremost, and consigns the machinations of the upper tier management of software delivery and work tracking second.
See the process guidelines for more info: https://learn.microsoft.com/en-us/vsts/boards/work-items/guidance/choose-process?view=vsts
Background:
JIRA offers a single set of statuses for all types of issues in a project.
Problem:
The problem is that the status set for a task is ToDo, InProgress, and Done. While for a UserStory in the same project it might be Designing, Developping, Testing, Releasing, and Done. It can even be different for a bug or an Epic.
Question:
How do you keep track of the workflow of your product and at the same time manage the status of your tasks using the single set of JIRA status.
PS: I know they can be customized for each project, but it doesn't help because you can't customize them for each issue type separately.
I think one of the reasons that JIRA offers the To Do, In Progress, and Done is that these can apply to anything. You either haven't done it, you're doing something, or you finished. That set can apply to any type of item.
That being said, I feel your pain in wanting to have a better view into the true state of an issue. What we have found we use for our OnDemand agile boards is to set up something like the following:
To Do
In Progress
Ready for Review
In Review
Done
For most types of issues, this can work. It adds that bit of extra layer to be able to identify what is ready for testing.
One of the things that is tricky is dependent tasks. For example, I noticed you mentioned "Designing" as a stage, and I'm not sure this makes sense in an agile sense. If the design is emerging from the development, it may be better to allow the design/development to flow within the development team. However, we all know that sometimes you need to get some details ironed out before you can proceed, or there may be some people that need to become involved before a dev can proceed. We made the mistake of trying to turn this into a stage, but what we found was that this was really either a sub-task for part of the team, or an impediment (blocker). By flagging stories, you can identify that a story requires something to be done before the development team can proceed.
If you are using Kanban, and not a Scrum board, the sub-task approach will not be for you. In those cases, you'll just need to make sure you have stages that make sense for all the issues you create. Stages will have to be fairly 'generic'. This sounds bad.
But it is not!
I believe teams generally use the stages for a few reasons:
Checking on status of an iteration
Inform other team members that they can pick up an item
Try to get a visual estimate on how close to Done an issue is.
More stages doesn't necessarily give a better status on an iteration as you really just need to see how many points you've closed and how many are in progress. So, at least for that goal, a more generic set of stages should work.
As for informing team members, too often I've seen teams retreat to the digital board to replace communication with each other. The fewer stages you have, the more you can force your team to talk to each other and work together to get a story to done. Things will work better this way, I guarantee it! Having a bit of a break-down helps, especially if you are working on a lot of items at once or have distributed teams working in different time zones, but keeping it simple is usually better.
Tracking the "how close to Done" is the hardest to do with generic stages. However, the multiple stages can be misleading. An item that is almost all the way across might have a severe bug in it that hasn't been found yet, so no matter how many stages you have your view on this item isn't any more accurate than a single "In Progress" stage. It isn't Done until it's Done :)
This was a long way for me to recommend keeping your workflow simple and letting your team use communication to keep on top of things. Maybe I should have just started with that!
The statuses that are available to each project is determined by the Workflow to which it is assigned. Not only does a workflow define the statuses, but it also defines what statuses you can progress to from a particular status. You can either create your own Workflows or you can download predefined workflows that suite your need.
In order to have separate workflows for different issue types, we need to define a Workflow Scheme:
1- Go to Jira Administration -> Workflow Schemes
2- Edit the Wokflow Scheme that is assigned to your project
3- Click the "Add Workflow" to add a new workflow for the issue types for which you need a different workflow and assign those issue types.