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.
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
(Posting the question here as this is the 'community' that Microsoft redirects to with a 'Need advice? Ask community' button. Hope it won't get closed as 'primarily opinion based' or 'too broad')
Hello,
I want to start using AzureDevops in my department for organizing code & work. We're a small team who creates a large number of applications & plugins.
Some of these applications have a very short lifecycle, i.e. we deliver them, and they work for years without changes. Other apps are larger and are updated/fixed across several months or years.
These applications are completely separate from each other in all aspects.
As far as I understand Azure DevOps structure, my department should become an 'Organization' (we can/need to be separate from the rest of the corporation).
I am a bit puzzled about the 'Project' part. Documentation says
In general, we recommend that you use a single project to support your organization or enterprise.
So, let's say we do have one project called Our Apps - where do we then put all the individual application-projects?
As far as I understand, each product (application) that we deliver should have it's own repository (or a set of applications, if they are logically connected).
This is in order to allow a developer to simply clone the repo on their machine and contribute to that product only - without downloading other projects etc.
I need to be able to:
easily navigate/see all the tens/(hundreds?) of applications that we create,
view their separate kanban boards (for those project that do have it, not all of them will)
to see their repositories (Git or TFS), commits etc
see & manage their pipelines
At the moment it seems to me that the only place where I can see a 'list' of what products do we have is the drop down below:
And the only way to see what is going on in the big-enough-to-get-own-board products is by creating a new separate 'SomeApp Team' in the Project (even though same people are in it), so that I can have a board for the SomeApp - and view the boards from here:
Is that the intended way to organize the structure?
Any alternative approaches?
Is there any way to have a 'cross-reposistory' or 'cross-team' overview?
What about creating documentation for each 'product'?
The "one project to rule them all" was coined by Martin Hinshelwood and his blog post from way-back-when explains the reasons and limitations.
With the introduction of Tagging and filtering on the backlog there is an alternative approach within the one-project setup.
Create team for the real teams you have in your organisation.
Create an area path for each major project/product in the org.
Assign the area paths of the projects to the teams who are working on them. This can change over time.
Optionally tag work items with the major project/product for additional filtering.
This way each team sees a complete view of all the work they can pull from. And they can quickly filter the work by tags to remove items from view when discussing specific projects/products.
Also, when teams change their focus from one product/project to another, you can simply change the assigned areas for that team to update their view.
The Plan View extension provides an additional cross-team view across over all the work. And the Dependency Tracker extension can visualize dependencies over time.
You can also use the Epic/Feature/PBI|UserStory tree structure to create additional grouping in your work items. You can customize the process template to introduce a Product level, though for the planning features to work, that would also mean that you'd also have to create full traceability from Product down to PBI|UserStory.
The main recommendation is to try a few of these approaches in a light-weight manner to see how they work and find your own ideal setup.
Another option for cross project visualization is to enable the Analytics Extension and connect it to PowerBI.
As you'll soon figure out, naming guidelines for your Tags, Repositories, Pipelines is going to be very important. Being able to quickly filter to the right level requires this.
I am creating a new VSTS environment and based on my research, I came up with the following recommendations to our team.
Scaled Agile Concept - Maps to (within VSTS)
Company - Team Project
Value Stream - Value Area
Products - Areas
Epics - Epics
Features - Features
Stories - Stories
Tasks - Tasks
Could you please help with pros and cons of this approach?
Alternate is to create a new work item type called "Value Stream" and new work item type called "Products" and link everything through parent-child relationships.
Or are there any other recommendations that you have?
Daniel Mann has provided great explanations for the definitions in case TFS confused by team, area, project, area, iteration:
A Team Project is an organizational unit for source code, work items,
build definitions, release definitions, manual tests, etc. You can
have multiple Team Projects per Collection. A Team Project can best
be thought of as "a collection of software applications and all of
the associated artifacts necessary to plan work, build, test, and
release the applications".
A Team is an organizational unit within a Team Project allowing
multiple teams to work concurrently on different aspects of the
software portfolio. Each team can have its own backlog, dashboards,
etc. Teams are associated to Areas.
An Area is an organizational unit within a Team Project used for
grouping similar work together. An area can be assigned to a Team,
meaning any work items that appear in that area are in the domain of
that team. Areas can have any hierarchy you want, and the names do
not necessarily map to anything like a Team Project name or a Team
name.
An Iteration is used for defining your work item backlogs and
sprints/iterations. A team is usually assigned a backlog iteration,
and then sub-iterations define the sprints and associated start/end
dates for work.
You could also get more information of process template in the following link:
https://learn.microsoft.com/en-us/vsts/work/work-items/guidance/choose-process?view=vsts
In Visual Studio Team Services, what are the best practices when creating team projects?
Is it one project for the enterprise? One project per actual project? One project per team?
With TFS, I've read many recommendations to use a single giant team project with multiple areas (see Why You Should use a Single (Giant) TFS Team Project. Is it different with VSTS?
We will have mixed languages with different build processes that includes C, C#, Java, Python, etc. with a multitude of outputs including desktop applications, mobile applications, NuGet libraries that are shared, C libraries that are shared, etc.
Is it different with VSTS
No
Is it one project for the enterprise? One project per actual project?
One project per team?
It depends the detail requirement, as that article says there are benefits to isolating and separating the various assets of each project/team, creating a team project for each seems like the most intuitive way to achieve this.
However, the multiple team projects can cause significant hurdles if you wish to move data across a team project boundary, there is no easy way to move data from one team project to another.
To conclude, you can refer to that article to decide the structure of team project(s).
It depends on your exact situation. Regarding structuring of projects and teams, Visual Studio Team Services is not different to TFS on-premise.
See also this response which explains differences to consider between having a single project with multiple teams versus a multiple projects: TFS setup for one small team and multiple parallel projects
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.