Context
I'm managing an Azure DevOps organization that is intended for an entire global department, where several types of teams work and collaborate together. The entire use case is similar to internal customer support (there are Requesters needing something and Agents doing the work), for which we mostly use Azure Boards (and Repos for Wiki, but we don't use any Azure automation, pipelines and such).
Current structure
4 process templates - I believe I can base all projects on a single
master template, though
2 projects on each template
Idea
Consolidate all the projects into a single project. However, I am somewhat afraid of performance and cannot find good resources confirming (or not) if the platform can take large traffic.
Current traffic
7 projects
10k work items weekly, largest project produces 4k work items weekly
1700 users
~100 teams
Question:
Does anyone have experience with running one large project with such traffic?
The total size of our userbase is not that big - it's 200 so-called agents and probably 1500 requesters. These numbers will grow over time.
One thing that would be impacted for sure is queries, as now we're querying from those 4k items weekly, but in a one master project it would be each query looking initially into 10k weekly items.
One potential mitigation of this is archiving some work items to a separate project every, say, 3-5 months.
Ok, enough data. If anyone can share their five cents, it would be great.
Azure DevOps organization management - one large project?
This is a matter of taste selection.
Accoring to your Current traffic:
10k work items weekly, largest project produces 4k work items weekly
1700 users
~100 teams
Personal experience does not recommend consolidating all the projects into a single project.
Consolidating all the projects into a single project helps us see all workitems on one boards. However, since you have more work items, this reduces the efficiency of query and management.
Azure devops also limits the results of the query：
Related
I'm thinking to move to Azure DevOps. But I'm at the stage where it's hard to decide which option will be useful.
My Requirements:
Single dashboard for the current sprint to have transparency to
everyone in the team. No context switching.
Single backlog for all projects.
User stories & bug will be easily identified by project.
Reports by projects, teams, etc.
Service hooks - Microsoft teams, etc.
Source control - GIT.
Artifacts.
Test plans under one board.
I'm thinking of going with single project(multiple repositories)
But before going down this road I just want to know what are the pros and cons of both options.
In general, we recommend that you use a single project to support your organization or enterprise. A single project minimizes the maintenance of administrative tasks and supports the most optimized / full-flexibility cross-link object experience.
Even if you have many teams working on hundreds of different applications and software projects, you can most easily manage them within a single project. A project serves to isolate data stored within it. You can't easily move data from one project to another. When you move data from one project to another, you typically lose the history associated with that data.
So according to your situation, it is recommended to use a single project with multiple repos and multiple teams. For details you can refer to this official document.
Reasons to add another project
You may want to add another project in following instances:
To prohibit or manage access to the information contained within a
project to select groups
To support custom work tracking processes for specific business units
within your organization
To support entirely separate business units that have their own
administrative policies and administrators
To support testing customization activities or adding extensions
before rolling out changes to the working project
To support an Open Source Software (OSS) project
Ours is a service-oriented organization which handles multiple project at a time. We want to introduce Agile Methodology in our team to follow. But this methodology is not getting feasible our team. We tried to implement this by planning sprint 1 for 15 days sprint for a project, say Project A. But members allocated to complete this sprint's task, weren't able to complete it in 15 days, as they got shifted to some other projects B, C, D, E, F's priority tasks. In such case, the Project A deadline gets missed, and in turn we have to pay price for being in delay. We try not to miss date of delivery for majority of projects, but sometimes it does happen that due to many things on plate, we do forget the committed dates for project live.
We use Azure DevOps to manage the projects. We create Phase/Sprint to whichever projects its feasible. Currently there are total 100 projects on-board, senior mentoring + project managing team has only 3 people & members to do development/testing work is 18.
Each resource per day does works on 4-5 projects on average.
If the senior team asks the member to fill excel/csv sheet of work they did particular day, and import that sheet in Devops, then it will be easy for team to get their tasks on Devops board for on regular basis. But the senior members can't view work of all 18 members did for a day in a go. There can't click on 20-30 project's URL per day and check which work items were did by which member on a particular day or which work items are closed or in progress in particular sprint?
So they need a widget which provides consolidated data of all these 100 projects work items together. I have used pivot table widget, in its y axis does fits 18 members name but its x axis fits only 25 projects and not more that that. On click in Others column option also I am not able to view 100 projects projects. Other than that in this table, I am not able to differentiate the sprint-wise task too. I used Sprint overview , sprint burndown, sprint analysis etc. widgets but these widgets only give current project's current sprint data and not overall 100 projects' various sprints' (sprint 1, 2, 3 etc.).
This data is useful as this chart can be passed on to upper management for team's performance analysis. How fast or slow they are in resolving the work items.
So please help me in providing a solution, is it possible for me to have a consolidated view of chart/widget, where I can view work items (bug-wise, feature-wise, task-wise, user story-wise, test case-wise) assigned for 18 member-wise for various projects which are resolved/active/close/open under their name for a particular Sprint 1, Sprint 2, Sprint 3 etc.
It will be grateful if somebody helps to resolve this issue, Thanks in advance.
Pivot Table trail
Sprint chart
Currently, there is not such built-in widget that can consolidate views for multiple work item types, multiple users, multiple projects, multiple work item states and multiple sprints on Azure DevOps.
I also searched and tried some related Dashboard Widget extensions from the Marketplace for Azure DevOps, but did not find any available extension can meet your demands.
You may need to develop a custom Dashboard Widget extension by yourself following your demands.
You can reference to the documentation about "Develop a web extension" and "Extension samples" to develop yourself Dashboard Widget extension.
I am about to start a project for which we will use Azure Boards to track progress of our work items in Kanban-style. Would like to ask a high level question as I am a beginner in Azure boards and have to make a decision on how to set up 11 Kanban boards.
We have decided it makes sense to have 11 boards, one for each category of product in our company. A few pointers:
There will be a single team working through the work items in the eleven boards
There will be moments where the team will be working simultaneously with more than one board
The eleven boards should contain the same team members / columns, as the workflow is exactly the same across those 11 boards
My question: should we create 11 different projects OR 11 teams within a project to get our eleven boards? What kind of rationale would make me want to create different projects as opposed to different teams?
Thank you
When to add another project
In general, we recommend that you use a single project to support your organization or enterprise. A single project minimizes the maintenance of administrative tasks and supports the most optimized / full-flexibility cross-link object experience.
Even if you have many teams working on hundreds of different applications and software projects, you can most easily manage them within a single project. A project serves to isolate data stored within it. You can't easily move data from one project to another. When you move data from one project to another, you typically lose the history associated with that data.
Reasons to add another project:
You may want to add another project in following instances:
To prohibit or manage access to the information contained within a
project to select groups
To support custom work tracking processes for specific business units
within your organization
To support entirely separate business units that have their own
administrative policies and administrators
To support testing customization activities or adding extensions
before rolling out changes to the working project
To support an Open Source Software (OSS) project
If the above conditions are not met, we generally recommend that you create multiple teams in a project. Here is the official document you can refer to.
I have got 2 teams one dealing with Bug Fixes the other dealing with small enhancements and have created these 2 teams in VSTS.
I am now trying to plan the work for 2018 so that we have a guide on how much work we can schedule into the releases throughout the year.
I am trying to link the 2 teams and the work into the overall plan so that if (for example) we get more bugs than usual we can demonstrate what that is going to do to the overall plan as this will impact against the ability to deliver small enhancements as bug fixes will take priority.
You can use the Portfolio Management settings of VSTS. This allows you to specify work at a higher level such as epics and features and then distribute the work across multiple teams.
You can then use the Delivery Plans extension to plan work across multiple sprints.
I think this question belongs here (but it is may get voted down). My company is migrating from GitHub to Phabricator. But, not sure how to implement the "boards" feature. I've never worked on a team that used kanban. We have created 8 different "projects" in Phabricator, but we are too small to have separate teams for each project. There are 4 columns for each board:
backlog
selected
in progress
done
How do people get 1 board for doing planning across projects. The only thing I can think of is to create a "master" project that every task gets added to in addition to it's "real" project. For example, an task might be:
Allow support user to resent password reset email
And it would get tagged with the projects "master" and "support_app".
Is there a better way of doing this?
You can plan an release and add milestones for product level and add multiple projects in it and spread it across team members in multiple projects in further small tasks.
Then you will have an individual task board for each team on team level tasks.
A team member then exist across multiple projects and you can also view , how an person is loaded across multiple projects.
If you want to look at bigger picture then you can see the milestones/release level status.