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.
Related
I totally understand what are story points and their advantage and inconvenient, but I'm trying to motivate the team to move to Azure DevOps, and currently we do not use story point(but rather estimations done by the whole team). I know it's not ideal, but it's not the point.
I would like to know if it's possible to configure Azure Devops to not work with Story points but with effort?
Thanks!
Just as Matt pointed out in the comment, you could choose to use Scrum workflow instead of Agile workflow
Effort is for Product Backlog Items (in Scrum template) and Story Points is for User Stories (in Agile template).
Effort
Estimate the amount of work required to complete a PBI using any unit
of measurement your team prefers, such as story points or time. A
numeric value is required.
Once a Scrum team have completed the product backlog item estimates they then go on to break each PBI down in to tasks. They then do time-based estimates on the tasks (e.g. Task 1 = 2 hours).
More detail info and process you could refer our official doc--Scrum process work item types and workflow
Update:
It's controlled by working days and Capacity per day, you could simply refer below sample screenshot.
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.
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.
Asking this here rather than softwareengineering, simply because there is a tag for VSTS here while there isn't one there...
So currently I'm seeing this:
What I'd like to see is 'Tasks' in there alongside Epics, Features, and Stories, and have it mapped to the 'Tasks' WIT.
How do I do this?
I've had a look at https://learn.microsoft.com/en-us/vsts/organizations/settings/work/customize-process-backlogs-boards?view=vsts, but I'm not sure if that's what I want.
This can't be achieved with the standard Task work item. The Task Level is a special kind of level which enables the Task Board and iterations. The distinction of pretty artificial and it stems from the time when TFS didn't event have a Feature or Epic level and there were just two kinds of plans: Longterm (story, pbi, requirement) or short term (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.