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.
Related
Our team is having difficulties identifying tasks in a sprint that are open for work. We use Azure DevOps and assign our stories and tasks to a sprint iteration. Our team workflow is modeled after the DevOps Scrum template. All tasks are child work items of stories. Additionally, we set Successor and Predecessor relationships between tasks. We also set Successor and Predecessor relationships between stories. We typically break stories down into tasks small enough so we can swarm a story and get it done quicker. Identifying concurrent work is crucial for our team.
Typical Azure DevOps Sprint Taskboard
The sprint taskboard looks like a complete mess. Each story is a blob of tasks. Developers and testers have difficulty going to the sprint taskboard to find the next open task, because they need to view each task under each story to ensure the predecessors for a task are closed. I'm not sure how to interpret the taskboard view to get this same information.
Typical Work Item Relationships
Azure DevOps allows you to visualize a work item to show its immediate work item relationships. This does not provide enough context when stories have numerous tasks and the relationships between tasks are deep. Each task work item is a child of a story in addition to the predecessor/successor relationships between tasks. On top of that, we order tasks under stories as well.
To be honest, I frequently resort to creating flowcharts just like the one above. It gives a clear visual representation of an entire story from start to finish. You can clearly see areas in the workflow where we can assign work to multiple developers or testers. I just can't shake the feeling I'm missing something in DevOps...
Question:
Is there an automatic order to tasks in the Azure DevOps taskboard view that communicates the predecessor/successor relationships between tasks under a story, beyond the explicit ordering of tasks in the sprint?
Epilogue: I understand that this question will receive comments that we should break stories into smaller pieces, or that one developer should work on a story and we should plan stories that we can work on concurrently. I tried this approach with our team for years, and this is the most efficient way for us to complete work. I fought this hard for a long time, but the fact is the team does extremely well with this breakdown of work — except with identifying the next thing to work on.
The answer to your question is simply "No". You can however write a query and sort the tasks by Priority.
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
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
How can I see all items in azure boards which are actually not done in their right hierarchy. And further more, how can I see unparented tasks in the backlog to plan it for a sprint.
I use epics -> work for months, features -> work for weeks, user stories -> work for days and tasks -> work for hours. So I have unparented tasks and also tasks directly under features for example.
I think you should use iterations for weeks and use iteration backlogs to see the work scope for a week (About area and iteration paths (aka sprints), Define iteration paths (aka sprints) and configure team iterations). In this case all task (with parent features or epics and without parent) will be available on sprint backlog:
Plan task for epics:
Tasks in epic, feature and user story hierarchy:
Taskboard for a sprint:
If your tasks without parent and without sprint you can find it through the query (Create and save managed queries with the query editor):
Azure DevOps relies on strict tree of work items. So you must follow this hierarchy:
Epic
+ - Feature
+ - User Story
+ - Task
Tasks are either unparented or must be linked to a User Story for the tools to work. The idea is that your Work for Weeks needs to be broken down in one or more Work for days.
The alternative is to create a custom Epic and Feature work item in the "User Stories" level of the process configuration. That way they all end up on the "User Stories" level and can all have tasks directly under them. As a by-product you then can't easily build a tree like the one above.
It's only the User Stories that show on the backlog. Tasks only show up an Iteration backlog. If you want to do pure Kanban with different work item types on a single board including tasks, you'll have to define these all at the User Story / Product Backlog level.
Will be setting up first VSTS team project and picking the process template, it seems to be down to either agile or scrum. Reading other posts, it seems scrum is the simpler and for the most part it makes sense for our small team. However, I do not think we want to use sprints and the "sizing" method for kanban typically uses is more loose also. My question is if I choose the scrum template, am I forced to use the sprints and if not, can I remove them?
https://learn.microsoft.com/en-us/vsts/work/work-items/guidance/choose-process?view=vsts
https://learn.microsoft.com/en-us/vsts/work/kanban/kanban-basics?view=vsts
The concept of "Iterations" is a fundamental part of the work item tracking experience and you cannot change that.
However, there's nothing stopping you from setting up a completely flat iteration structure consisting of only a Backlog iteration with no defined start or end dates, then managing everything from the backlog view in a Kanban fashion.
There is no difference between any of the process templates in this regard, only in the work item names and in some rules around state transitions. I believe Agile has looser rules for state transition, whereas Scrum has stricter rules.