We have a small group < 4 but work on several different applications that we support. Each application gets its own Git repo, but as for managing the effort I really don't want to setup a separate team as well for each product.
Questions:
- For a small group working on several different products (eg. websites, services, utilities etc), can a single "team" within one project allow us to work on 2 sprints at the same time that are within different area paths?
- If I have already defined multiple teams, can I migrate all the content into the backlog of a single team?
- Assuming one team and multiple area paths, the project "hierarchy" would look something like this, correct?
Project
|__Team
Area-1
|__Sprint 1-n
Area-2
|__Sprint 1-n
Area-3
|__Sprint 1-n
[ update ]
On further inspection looking at the docs, the iterations can have their own paths. It seems that if we want to manage 2 or more simultaneous sprints or overlapping sprints that involve different products, it makes sense to go ahead and configure a team per product or possibly one team per "business area" (eg. Sales, Operations, Warehouse etc). Within a business area, our group would only have 1 active sprint at a time, which seems straightforward, compared to trying to manage multiple sprints within the same team.
https://learn.microsoft.com/en-us/azure/devops/organizations/settings/set-iteration-paths-sprints?view=azure-devops
So the better approach might be multiple teams, with one (default) area per team and a iteration list for each team.
The Team's areas and the Team's iterations are disjointed. I would think you could assign the different product areas (websites, services, utilities) to the team but then have just a single iteration list instead without trying to segregate the iterations by area. This won't work if the sprint dates for the different areas are different, but if they are different I don't think any approach you try to leverage in app will work.
Areas:
Sandbox
|__Team
|___Websites
|___Services
|___Utilities
Iterations:
Sandbox
|__Sprint 1
|__Sprint 2
|__Sprint 3
I don't think you will get to a good solution if the different product areas have different start/end dates for the sprint even if you could make something workable using the tool.
Related
I am a PO leading a small development team for enhancements to our PeopleSoft Campus Solutions application for a Medical School.
We are using the Sprint functionality in ADO to assign stories from our backlog to the Sprint, create the relevant tasks for each story (mainly development, testing, deployment) and assign the tasks to resources who, in turn, provide effort values (original estimate, remaining, completed). We also make sure our capacity is properly set, with resources OOO time and school holidays configured to get an accurate team and resource capacity. The team updates their effort numbers daily to ensure we are tracking burndown.
While we always start the Sprint with the remaining work hours under team capacity (and the same at the resource level), we have historically left alot of remaining work on the table at the end of the Sprint.
My leadership wants to answer the question "Why was the work left on the table?". Of course, there could be MANY reasons, we underestimated the effort, we were blocked on a task (for example, we can't start the testing task until the development is done), the resource didn't actually have the calculated capacity due to being pulled into other meetings or initiatives, or (and I don't think this is the case) people were just plain lazy.
What reports/analytics can I leverage to help answer this question? Even just seeing a list of remaining tasks per resource with remaining task effort and with a total amount of work remaining per resource overall would be helpful, but I can't seem to find anything.
Any suggestions or guidance is appreciated!
You can use Queries to find the remaining tasks(add column option->Remaining Work) and save the query into Shared Queries.
There is a query results widget in dashboard to display the query in Shared Queries. Do not forget to add Remaining Working in widget.
Remaining Work:
You could refer to the document: Adjust work to fit sprint capacity
I have a set of services that need to have a shared on call rotation split between multiple timezones. For example, I want the US team to take 16 hours shifts and the London team to take the remaining 8 hours. What is the best way to deal with this?
Create separate services to reflect the team split and have distinct escalation policies for each?
Use a single schedule with two layers to reflect the time split?
Also, should I have a single team for all or have one for each geo location? Would this get complicated if I have to add another timezone in the future?
I have two teams assigned to one project.
Currently, they're working using the same iterations.
Starting from new iteration I want to change this setting. One team (A) will work using iterations 2 weeks long, the other (B) 3 weeks long.
I am looking for answers to the following questions:
will team B board be cleared (I'm fine with that, just want to be 'ready' for that)?
will team A board be affected by the change of team B settings?
If I'm understanding your scenario & questions correctly, going into the new sprint (iteration) you would like to split your team's iteration duration. Team A to 2 week iterations and Team B to 3 week long iterations.
If that's correct, then changing your team's iteration duration shouldn't have an affect on the boards, meaning backlog and sprint boards. You may want to look at adjusting your team member's capacity. Also make sure when you create new iterations to add them to your team configurations, and look at what your teams' default iteration is.
For this issue , creating a new iteration for the team will not clear the previous team board.
And the change of team B will not affect team A.
You can switch iterations of different periods of the team in Spirits.
I have a number of teams in the Azure DevOps (Visual Studio Online) tracking a different type of work item.
Currently i have created 3 different backlogs for 3 different teams.
There is 2 default backlogs 'Epics' and 'Features', hence total of 5 backlogs.
I'm trying to added a 4th team and now trying to add a backlog for that team.
But i'm getting the message "You have reached the maximum number of backlog levels".
I also learnt that maximum number of allowed Portfolio backlog levels defined for a process is 5.
I also tried to edit the default backlog, which would not let me de-select the work item selected in it, so i could rename it and add the new work item it needs to track.
So is there any other way i could achieve that or to increase the number of portfolio backlog levels.
By default projects, your hierarchy is shown as below:
If you need more than two portfolio backlogs, you can add up to two more for a total of five backlog levels. (limits mentioned here. Portfolio backlog levels defined for a process 5)
This will increase the totally level to 7 (3 customized+ Epic+Feature+PBI+Task)
You can add them by customizing your process, adding new work item types, and then configuring your backlogs and boards.
You can also add or modify the fields defined for a work item type (WIT) or add a custom WIT.
After this it could be:
For details, see Customize an inheritance process and Customize your backlogs or boards (Inheritance process).
However, this is backlog level not designed for multiple teams.
Your team's product backlog lists only those items whose area path matches those assigned to your team.
For details, see Define area paths and assign to a team.
Then you could simply switch backlog for different teams here:
I think you may be going about this the wrong way with respect to Azure DevOps.
You should look into having an Area Path for each Team. See here. For instance in my company we have two Teams say; Alpha and Omega and we've set up two Area Paths as Company\Alpha and Company\Omega. You can then manage each teams backlogs, iterations, work items etc. separately. See here also. We use the same set of iterations across all teams and when we move work items between teams we change the Area Path of the work items.
I have a VSTS project based on the Scrum process with two Area Paths for frontend and backend teams. For all Backlog item boards I created a new column to indicate what is 'ready for testing' (splitted in doing and done). For the state mapping I could only chose 'Commited' from the dropdown list.
The root area is configured to include both sub-areas and should provide a broad overview for the product owner about the progress and the tester to see what he needs to do.
My problem is, that when a team moves an item to this column, the change of state is not reflected on the general board. How can I achieve this? Or what are best practices to deal with additional states like 'ready for deployment' and 'ready for test'?
Kanban board states are "per team" so you won't see the change reflected in another team's board (in this case, the top level default team).
If this was on-premise we could add a new underlying State to the Work Item so it worked across teams. I believe this is coming for VSTS but it's not there yet.
VSTS and TFS 2015 Update 1 allow you to Query by Kanban board changes which means you could have a Work Item Query which shows all the items across teams that are Ready For Test on the board.
Depending on exactly what you want to see in your query results, you'll probably have to do something slightly clever with grouping the clauses of your query - ie. (PBI Area Path = Area 1 AND Column State = Ready for test) OR (PBI Area Path = Area 2 AND Column State = Ready for test)