In my org, I have 4 teams and each of them will have their own backlog and will plan their sprints based on this. We want to have a main backlog where the product owners will discuss what work items will go into their backlogs
I would like some guidance as to what is the best practice to use Area path and iteration path to allow the different teams to plan based on their own backlog but also have a Mother of allboards for the POs to discuss and put it under the different teams.
Thanks in advance!
I would like some guidance as to what is the best practice to use Area path and iteration path to allow the different teams to plan based on their own backlog but also have a Mother of allboards for the POs to discuss and put it under the different teams.
In the Azure DevOps boards, it has default area path, if we create another teams, it will create a sub area area path under the default area path.
In my project the default team is test and I create teams test01 and test02, open project settings->Team configuration->Areas, we could see the test team area path is test, test01 area path is test\test01 and tesst02 area path is test\test02, switch team to test and click the button include sub-areas, check the pic below
Now we could see test01 and test02 teams work items in the test team backlog, we could create work item in the test team, and POs could discuss and change the area path to put it under the different teams. You could check the gif below.
There is detailed documentation to work with multiple teams. You can adapt some practics in your process:
Plans (Agile at scale)
How SAFe concepts map to Azure Boards artifacts
Configure Azure Boards to support SAFe
Agile culture
Since you mentioned 'Sprints', 'Product Owner' - I feel Scrum framework would be the best agile method. Product Owner has the final say on what goes on the 'Main Backlog'. When planning a Sprint, I expect you are going to involve all 4 teams. Azure is the best tool to maintaining and delivering backlogs.
For POs and mother of all boards you may have to rely upon a different tool like Asana.
Thanks
Related
How can we restrict access to edit/move backlog boards in VSO from one section/column(New/Committed/Developed/Done) to another section/column(New/Committed/Developed/Done).
we are facing issues as there is no control on board movement for our project.
Thanks in advance.
To move backlogs from one section to another section on the Backlog Board, one needs to have the Edit work items in this node permission for the Area and Iteration path. You can deny the permission to disable the ability for that specific engineer.
Go to the team project admin page (https://vsoaccount.visualstudio.com/DefaultCollection/teamprojectname/_admin/_areas), right click the Area and select Security. Select the engineer you would like to set the permission to set disable that permission. See:
Per my above screenshot, user Victory Song can't move work items which is under Agile area. (and she can't edit work items under Agile area either.)
I am using TFS 2012/VS 2012.
I have five work items available to me: Bug, PBI, Task, Test Case and Impediment. I cannot figure out how to access user stories, and none of the information put out by Microsoft is very helpful.
I suspect the template that was used to create my project did not include them, but I am not sure. Is this true?
Can I alter my existing project to add user stories or requirements?
When creating a new project, which templates will automatically contain user stories or requirements?
Looks like you used the Scrum Template to create your Team Project. Only the Agile Template includes User Stories by default.
You can use the witadmin.exe tool to add additional Work Item Types to an existing project.
In Scrum PBI is the equivalent of a User Story (and in CMMI the Requirement is the equivalent of a User Story).
I'm new to TFS and we're loving it! I'm having a difficult time figuring out how best to organize TFS from version control and agile/scrum/sharepoint sites, keeping isolation of teams yet sharing of code and projects.
For this scenario let's say I have three teams. Team 1, 2, 3. I want each team to have access to only projects they work on, and each team to have isolation for alerts and notifications, sharepoint, agile, etc. So let's say there are 5 total projects.
Team 1:
--Project 1
--Project 2
Team 2:
--Project 1
--Project 4
--Project 5
Team: 3:
--Project 1
--Project 2
--Project 3
--Project 4
We have one collection setup, DefaultCollection. Right now I only have one team but this doesn't give us good isolation and separation of the features. How can I best configure TFS to keep separation of teams but not have separate code projects? Some projects are shared and this is the point of contention - I don't know how to handle this part.
Acme Widget has X projects and then we have a "Company Shared" with X projects. We may be working on different products such as Acme Widget 1, 2, 3 but all share and work on the Company Shared projects, i.e. Company.Utilities, Company.Windows, Company.Security.
Can someone please shed some light on how to properly configure TFS while we're early into the stages of use. We want to go beyond just version control as mentioned above. We want to use the Task, Bug, Alerts, Build, etc.
P.S. If anyone is a TFS sub-contractor that helps organizations configure their TFS setup I would entertain a professional consultation and configuration.
Since TFS and SharePoint aren't actually holding the user accounts (they are inside Active Directory). It would probably be easiest to create an Active Directory group for each team and place your users in that group. You can then still keep one project collection (no need to over-architect) and then everytime you create a new project within that collection you assign the permissions to that project (TFS, Sql Reports, and SharePoint) using the Active Directory groups. You should download the free TFS Administration tool to manage permissions and when a user joins/leaves a team then you can manage that directly in Active Directory without changing TFS, Sql Reporting or SharePoint. This seems to be a very common approach starting when this issue arose from early SharePoint days when admins were trying to independently manage SharePoint groups and Active Directory groups.
I would suggest that you look at this:
http://blogs.ripple-rock.com/colinbird/2012/11/19/MultipleTeamsWithMicrosoftTeamFoundationServer2012VisualStudioScrumV2xUpdated1452013.aspx
This shows you how you can have multiple teams, which each of theirs board, tasks etc.
We use this in our company because its the same project, but 2 different teams. Then it works perfectly because we have the hierarchy of teams:
-- Project (level 0)
---- Team A (level 1)
---- Team b (level 1)
In that way we can assign stories or tasks to either the one of those, and if they are assigned to the project level (level 0), then it will appear on all teams.
How can I customize share point portal and do it in a way that is easy to create and maintain. Below is a sample of the portal I inherited from someone else who was using images all over. I outlined in red each image. This image method introduces a lot of rigidity and loads of manual labor to make updates and changes.
can this be done using CSS or somethign other than images?
I tried using this site but i think it falls short and only allows customization of basic share point objects.
As a bonus i would like to see if its possible for each portal in the group that represents a particular project pull project related details like "milestones" from a SQL driven project management system we had home grown. Our team has about 25 projects at any given time.
For SharePoint Branding questions then Heather Solomon's blog is the first place to go to.
Especially have a look at the Resources on the right such as the CSS reference
I was thinking of having a tree structure with every team at the top and then having all projects underneath the teams. Something like this:
sharepoint/team1
sharepoint/team1/project1
sharepoint/team1/project1/sub-project
sharepoint/team1/project2
sharepoint/team2
sharepoint/team2/project1
sharepoint/team2/project2
sharepoint/team3
Team1 team2 team3
project1 | project2 project1|project2
sub-project
The problem with this structure is that we are having some few projects that are between several teams.
How do you think that I should structure it?
I would have a totally separate 'Projects' tree (possibly even a site collection), and just link to each project as needed (possibly with a 'members' list on the front page of each project to show who is associated with the project). That way, if the project changes teams you won't have to reshuffle the site hierarchy.
You do not need a separate site collection for this. Just create separate Team Sites for each project and create a SharePoint group (will contain members from different teams) and assign it to each "project" site. Now you can create security-trimmed menus out of the box.
It is very common to want both project and team sites. However, the desire doesn't always make sense so it's best to so some due diligence with your audience/s.
Assuming both sets of sites make sense, I second Moo's advice: use a separate "tree" of sites for each. If performance, scale or ease of administration is a concern these can be places in separate site collections (and SQL dbs). However, this is not necessary per se.
Getting the site collection structure "correct" up front is less of a concern now that the STSADM tool is able to split/combine them after the fact. Also, it's sometimes easier to get it "right" once you see how people are using (or not) the sites.
Good luck!