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.
Related
I've been using Azure DevOps Dashboard for a while now and it's working nicely. One gap I have found is in it's Lead Time Chart. This goes from date creation to date completed, which in an Agile world doesn't make sense.
Backlogs can be thought of a placeholder for a conversation, following this initial backlogs can be vague and poorly defined, and more information and clarity will be added as the backlog moves closer to being actionable.
What I would want is a "Estimated to Completion". SCRUM teams estimate when there is enough information that the item could be pulled in to a Sprint, and this is the point where the lead time really makes sense.
Is it possible to add this to the DevOps dashboard, is there a query that will give me what I need?
Thanks,
John
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.
We're using an inherited Scrum process in MS DevOps Service and recently created a new team that combines two old teams to provide a 'one-stop-shop' experience. However, when we go to look at the Sprint Backlog or Taskboard, we don't see all the work items because we are over the 1000 item limit.
Is there a way for us or Microsoft to increase this limit?
Each backlog can display up to 10,000 work items. If your backlog exceeds this limit, then you may want to consider adding a team and moving some of the work items to the other team's backlog.
For Taskboard , you can have up to 1,000 tasks on a task board. Like backlog, you can consider adding a team and moving some work items to the other team's task board.
Currently, the work item limits are as designed . I am afraid that these limits cannot be changed. You could add your request for this feature on our UserVoice site, which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.
For detailed limits ,please refer to this document.
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.
With the ability to configure how the bugs should manage, I'm confuse what to select as a process when I create a team project in VSTS 2017.
In the Microsoft guidance they say Agile
works great if you want to track user stories and (optionally) bugs on the Kanban board, or track bugs and tasks on the task board.
But even I select Scrum as the process, the bugs can be configure not to manage on the Kanban board.
and further
Choose Agile when your team uses Agile planning methods, including Scrum, and tracks development and test activities separately.
Isn't this same even I select Scrum as the process? I couldn't see any differences from the interfaces.
Of cause by choosing, Agile I can track original estimation and the completed work alone with the reaming work.
So what are the other differences, which I go for a one over the other? May be some reports like Stories Overview Report
Regarding Bug tracking, the workflows are different: Workflow states, transitions, and reasons.
For Agile process, the forecasting is based on Story Points and for Scrum process, it is based on Effort.
Regarding report, the link you provide is used for on-premises TFS. You can show report that you want in the custom widget or hub extension, so no difference.
Write your first extension for Visual Studio Team Services