We'd like to set up TFS2012 to handle the multiple work methods per project problem. Did see the related topics, but I think our case is different.
We have several products with one or more teams working on them. The teams see the product's backlog, but they may use different work method - a project can have a scrum and a kanban team. In some cases a kanban team does release work on the user stories which are finished by the scrum teams.
How should we start setting up TFS to have different work methods (templates) within a project? Should we use one project collection? Is there a template which can handle scrum and kanban work together Can we modify and map a workflow to two different boards?
Thanks!
Each team project is based on a single process template. In this case you can either choose the Scrum or the Kanban template, and customize it.
It seems Scrumban process would fit into your project, however there's process template available yet for TFS.
Related
We have a department team section in JIRA setup as a project and I have been asked to create Kanban boards and set the section up ready to use but I'm not sure the best way to apply the work the department team is managing into JIRA.
We want to have Kanban boards for two different specialties and for e.g. one of the specialties we have two projects and one of the projects has a subproject and also one of the projects may sometimes overlap with both specialties.
For example:
Build team
Development Kanban Board
Project A
Project Sub Project/Stream A
Project Sub Project/Stream B
Project B
Test Kanban Board
Project A
My current thoughts are:
Project = Team
Component = Project A
Epic = Project Sub
Project/Stream
Labels = Specialty Kanban Board
Is the above correct or is there another approach that would be best practice for this scenario? At the moment I think we are tied into having the Project in JIRA set as the team
Usual practice is to make your projects correspond to JIRA projects (thus the name). You can set up the filters for Kanban boards to bring in issues from multiple projects according to whatever criteria you want. This will make it easier if issues need to flow from the dev team to the test team. The "Team" can be defined by assignee, status, or another field if you prefer. Epics are good for time-bounded subprojects, components are good for ongoing subelements (e.g. UI, database, etc.).
I've recently completed the deployment of TFS 2015 Update 1, we have around 15 development teams in the UK and previously we have always structured our TFS projects as follows:
Default Collection
Application 1 (Team Project)
Application 2 (Team Project)
This caused issues with sharing work items across teams as it is difficult to move WI's across the project boundary.
Rather than create a new team project for each team, I want to manage things with a single team project and create separate areas\iterations\teams for each one. So:
Project Collection > Master Team Project > Area 1
Area 2
Area 3
etc
in terms of permissions I would like to add in each of the standard TFS permission groups to each area. I would also like to create a root folder for source control for each area.
At the moment I can't work out how to do this? Can anyone help?
I suggest you to look at the some community suggestion on this topic.
One Team Project to rule them all
Why You Should use a Single (Giant) TFS Team Project
How to implement a multiple team strategy in Team Foundation Server 2013
In general it is a good practice (I won't say best practice as it is not the right thing to do in some cases).
Regarding you question, you should focus on Team to define developers access, and TFS groups for general (e.g. administrative) access.
I'd recommend you to use the multiple teams feature in TFS2015. It allows you to manage the team members, permissions, work items more easily. And you can track the entire project status from the team project page and track the individual feature team status from their own project page. The work items can be also moved between the teams easily (Just change the area path). Refer to this link for details: Multiple Teams
I have been reading a lot on the recommended project structure in TFS. I am considering moving my company to Visual Studio Team Services (was VS Online) and have been trying to set up and test to get my head around how it will work. Based on articles I have been reading, it is recommended to have one team project with many areas/iterations/teams (http://nkdagility.com/one-team-project/, http://nkdagility.com/working-within-a-single-team-project-with-team-foundation-server-2012/).
What I am struggling with is how to make this work for my specific environment and what I would like to see. We are a small development team consisting of myself as a manager and 2 developers. With our current structure (outlined below), I cannot see across team projects for our full backlog. To see how individual work is progressing, I would have to go into the individual team projects.
Current Structure
TFS (Server)
Accounting (Collection)
Application 1 (Team Project)
Release
Test
Application 2
Engineering
Application 3
Application 4
I like the idea of being able to see a master backlog and then assign work items to the individual projects. However, I would still want to be able to manage sprints and see burndown charts down to the individual project level. For example, if developer 1 is working on Project 2, I would like to assign PBI's to that project and see the burndown chart at that level.
New Structure
Team Services (Service)
DefaultCollection (Collection)
DefaultProject (Team Project)
Accounting (Area)
Application 1 (Application)
Application 2
Engineering
Application 3
Application 4
Basically, as a manager, I am looking to be able to see a status of where we as a department stand in our overall backlog. As a developer, I want to know what items are assigned to me, regardless of which application they are related to. Am I on the right track for this? In typing this question, I've almost convinced myself that I don't actually need to know backlog of an individual application. Rather, I should be managing all of the work across all applications and using that as a sprint backlog. Sometimes this sprint will be multiple releases in larger application and sometimes this sprint will be updates across multiple smaller applications. Any help that can be provided to help point me in the right direction will be appreciated.
You can create multiple teams in the same Team Project and you can nest them to facilitate hierarchy.
http://nkdagility.com/creating-nested-teams-visual-studio-alm/
You can see how to configure this in my post above. It's fairly easy to use...
The new structure is good. And you can create two teams from your project Control Panel\Overview: one for Accounting and one for Engineering. Check "Create an area path with the name of the team" option when you create the team. Then you will have 1 overall project page for your team project and 2 sub project page for Accounting and Engineering like following:
In the overall project page, you can manage your overall backlogs, check the Burndown charts for the whole project. And in the sub project page, you can manage the backlogs and check the Burndown chart for individual project.
What is the recommended organizational structure of team projects in TFS 2010? Let's say we have 4 big departments within our enterprise. Is the recommended approach to create a team project for each department or logical representation of one's organization and have different folders for VS projects within those TFS team projects? Or should each reasonable big project have their own team project?
I am asking more from a perspective of code storage and TFS artifacts. If we are to store both code and user stories, tasks, etc. in one big team project, does that hinder the agile development process? We can still setup separate queries and a separate dashboard for each "project" within the big team project. However, the builds would be in this giant list of builds.
If we had many smaller team projects, it would be more difficult for QA to span their work across multiple team projects. They'd need to know where to enter bugs - knowledge that we don't necessarily want to rely on.
So what is the best practice?
Storing everything in a single project will not hinder "the agile development process". My recommendation would be to create an area path for each project, and organize your work items under those area paths. You'll have a product backlog query for each area. Use the iteration path field to then drive a schedule across all the projects. That should work fine. All the reports can then be filtered by area and/or iteration.
For builds, I see many teams prefixing build definitions to provide better organization. Here's a blog post that describes an extension you can download to help better organize builds.
http://blogs.msdn.com/b/bharry/archive/2011/04/01/build-folders.aspx
I would like to know what is the concept of Team Project in TFS 2010. In my company, there is a single team working on multiple products at the same time. There is a visual studio solution for each product. We are following SCRUM methodology. Our product back log and sprint back log basically comprises of items related to multiple products, so during the sprint the team works on backlog items relating to multiple products. We are looking forward to use SCRUM Process template for TFS 2010.
I was wondering what approach should i take in terms of organising the projects in TFS Source Control and making full use of the TFS Process Template(SCRUM)?
Should I create a Team project for each product? But that would mean I will have to maintain process template, product backlog and sprint backlog for each Team project. Especially when creating and querying work items, it will involve lot of switching between team projects in team explorer. Similarly, when creating burn down charts/reports, there is going to be one for each of the Team project. This seems like a nightmare!
Or should I create one Team project and put all the products(Visual Studio solutions) under it? This sounds better to me because, there will be one process template, one product and sprint backlog and one place to look at/query all work items.
To me it seems like Team project should map to a Team and not to a Product or Visual Studio Solution. However in my past experience, I have come across places where Team Project is mapped to product/visual studio solution and I am a bit confused.
The term "Team Project" is confusing. I really wish Microsoft had used a different phrase.
Having said that, I don't know what other word or phrase would apply.
A Team Project does not necessarily correspond to a Visual Studio project or solution
A Team Project certainly doesn't correspond to what SourceSafe used to call projects (those were just folders)
A Team Project doesn't necessarily correspond to a single source control tree. The people working on a Team Project may use code from multiple source control trees (assuming this can be mapped into your workspace correctly).
A Team Project more closely corresponds to an endeavor of some kind. This may or may not involve some source code. It will involve some people. It may or may not involve some work items, or builds, or reports, or portal sites, or lab environments, or any combination of those artifacts that are scoped on a per-team-project basis. These will usually be artifacts that will be useful to some "Team" in accomplishing their "endeavor" (which may just happen to ba a matter of producing and releasing some code, using the help of work items, reports, source control, builds, etc.)
I would advise you to create one team project and multiple folders for different solutions.
In other words leave your work as it is and create just one team project.When checking in products codes use server folders. This way you have a unique repository with shared work items and reports