Azure Boards works very well for teams doing scrum. With scrum, iterations work well at task board level.
For kanban, however, the task board's need for iterations makes for kludgy setup of fake iterations.
Does any official guidance exist explaining how to do kanban with Azure Boards?
If you want to use Kanban with Azure Boards, it makes more sense to use the Backlog board instead if the task boards. The Backlog board is was more customizable and it focusses in the level that is important (assuming your backlog has the items of value). You can decompose the PBI/User story on the cards themselves by adding tasks is tests.
That way you don't need any iterations at all at the sprint level.
Related
Azure Devops allows to see PBIs and their associated tasks on sprint taskboard. But what if I want to see the associated Feature or Epic of each PBI?
Is there any way to add a column for Epic or Feature?
Not a direct answer, but I believe what you're looking for is the Boards section.
Sprint taskboard is useful for detailed viewing of specific tasks (e.g. on a daily stand-up).
Boards taskboard is useful for higher level, basically anything above tasks/bugs. Including epics, features, PBIs, etc.
The trick is to use both of these taskboards in parallel. Sprints for details, Boards for bigger picture.
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.
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.
When using Kanban boards in Azure DevOps, if the story is split into tasks, is there any support for working with tasks?
In the below image we can see the tasks with yellow under the stories but that is not easy for the developers to use. The task board can only be used if also working with sprints.
I haven't been able to find any documentation related to this. Are tasks supposed to be used at all when using a Kanban board?
Are tasks supposed to be used at all when using a Kanban board?
No, I'm afraid there's no such feature supported in azure devops boards now.
Because this is by designed based on the concept of Agile process.
See this Agile process workflow:
For Epic, Feature and Stories, they are all belong to Portfolio backlogs, while tasks is iteration backlog.
For our Azure devops Kanban Boards, it used to display the Portfolio backlogs for management team. You could add additional customized portfolio backlogs level by modifying the process your project is using.
But you could not change the tasks from iteration backlog to Portfolio backlogs. Because this does not match the basic concept of Agile process.
For Azure DevOps Boards, the Boards view visualizes the Requirement Backlog which is typically a User Story or Product Backlog Item, but it is not meant for moving Task states. For moving a Task between states, the Sprints view is used:
In my experience, for a team using an iterative methodology like Scrum or the Agile template, the Sprints view is likely more heavily used than Boards and the opposite is likely normal for a team using Kanban since Boards visualizes the requirements nicely for flow. Hybrid methodologies like ScrumBan could use both. Whatever works best for the team.
See this table and more information here:
Microsoft Planner or Azure DevOps
We need to keep a track of tasks assigned to DevOps teammates.
I checked Azure Devops.
Azure DevOps gives you tasks and issue so that you can assign it to the members.
Not sure what MS Planner offers and should we chose that over Azure DevOps
Microsoft Planner is a task planning tool integrated in Office 365.
The level of capability from low to higher is corresponding task management to project portfolio management.
For a detail tutorial you could take a look at this link: Microsoft Planner - Step-by-step guide for users
Azure DevOps is a cloud-side source code management system also offering project management features as part of Microsoft's application life cycle management solutions. More project management features are accessible.
In Azure DevOps, you could also track work with Kanban boards, backlogs, team dashboards, and custom reporting.
Combine drag-and-drop sprint planning and flexible work item tracking with comprehensive traceability to have the perfect home for all your ideas–big and small.
You could also use the visualization options provided by Delivery Plans to review the schedule of stories or features your teams plan to deliver. Delivery Plans show the scheduled work items by sprint (iteration path) of selected teams against a calendar view.
Delivery plans is also interactive. You can change the assigned sprint of a work item by dragging it to a new sprint as shown in the above image.
I couldn't directly give you an accurate answer which one is better, it's all based on you and your team's requirement. They are totally two different products. Please kindly select the one suitable for your sides.