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.
Related
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：
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.
Our company has recently introduced Azure DevOps to streamline project management process. Currently, 140 projects are created under our organization in Azure DevOps. As and when requirement comes from client for any specific project, we create tasks/bugs for different developers under that project. Currently we use only two Work Item type - Bug and Task.
Now the issue is Management of the company wants to see Project-wise number of "New/Open", "Active" and "Closed" Tasks and Bugs in a SINGLE chart. That means, that single chart must fit consolidated data of 140 projects. If a person views that single chart they must get idea, for example that - Project 1 has 2 new/open work items, 2 active work items and 2 closed Work items , Project 2 has 1 new/open work items, 10 active work items and 3 closed Work items and so on.. This is done so that management in a glance can understand which project is lagging behind for customer delivery. So that they can work accordingly build more manpower for those Projects.
I have tried to create various such charts and widgets with different queries in Azure DevOps. I used widget burn up and burn out charts but it gives data for tasks of single Project only. Also when we add multiple projects to it, it shows summation of completed/remaining tasks for those Projects & NOT Project name-wise completed/remaining tasks bifurcation.
I also tried "Charts for work item" widget but it also fetches count as per- Assignee, State and Work Item type and not project name wise count is fetched.
I don't want to navigate through 140 projects pages to see it's open, active and closed tasks. So please help me out in suggesting the ideas on How can I build a single chart from where we can get all this data? I will be forever grateful for your answers.
Thank you!
You could create a query across projects, select Team Project column in Column option, ad save the query as shared query. Check the screenshots below:
Then add a chart widget to a dashboard, select Pivot table, and set Team Projects, State as Rows and Columns. Check the screenshot below:
You could expand the view to see more details:
https://learn.microsoft.com/en-us/azure/devops/report/dashboards/charts?view=azure-devops#add-a-chart-widget-to-a-dashboard
I'd be slightly careful based on what you've put down because I don't think your management team quite understand what they need, and DevOps can only do so much. I'd be challenging them around the setup of your DevOps process personally because I don't think it's advisable to not have user stories as part of your setup. Although it simplifies some aspects of DevOps, our experience has been that people have been able to group things together better with user stories as well as tasks.
Appreciate it's a good idea to be able to see what's going on across all projects, but I think there are probably further criteria to think about. E.g. do you want to see estimates instead of/as well as the count of the items since that will have a better reflection of the effort required. In terms of completed items and in fact, probably all that you're displaying, again it's more on your project process, but are management genuinely interested in everything? For example, do they need to know that something was closed 6 months ago, or are they just interested in the last month?
I suppose what I'm getting at is you probably need a bit more information from management about what they want to use the report for so you can give them what they need rather than they want. There's a temptation to say you want everything because you don't understand the capabilities of the solution or what you're going to use it for, and my recommendation would be to challenge them on this so you can better present things (giving them what they need rather than what they want).
In terms of what you're looking to do, I'll openly admit I'm not clued up on everything DevOps related but I doubt you'll be able to report at a project level within DevOps. I think what you'd need to do is set up your query, which would look across all projects in your organisation, and then export the results to Excel. From there I'd create a pivot table (or perhaps more than 1) with the data that you need. Have Project names down the left side (row headers), and bring in whatever else you need as columns. I think that's probably a good quick win to get something in front of your management team, and then you could challenge from there - almost picking holes in it so that they realise that the business decisions that they'd make from this may not be fully informed, and suggesting some changes. From experience, it's probably better to consider it almost as a prototype and not get bogged down with a solution at this stage because you may be asked for changes when they can visualise what they've originally asked for. Once management is happy you could look at other solutions to provide the report, but Excel is typically a good starting point I've found in the past when working on something new like this.
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.
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.