The boards: Work/Backlog/product backlog/board(the stories/backlogitems) and on Work/board(tasks) can we have different column mappings per teams? Currently the type - value pairs are stored in CommonConfiguration, so it is project based, can we change it to be Team relative?
This totally depends on which update you are on (if you are using on-premise TFS). If your TFS deployment is Update 2 or higher - or you are using TFService - you can customize the "Kanban Board" (the board that shows work items on the backlog), link here: http://blogs.msdn.com/b/bharry/archive/2013/02/01/customizable-kanban-swim-lanes.aspx. This allows you to change the columns, per team, without changing the workflow of work items themselves.
As for the Task board, you can customize it, but only for an entire team project. This must also be done via the CommonConfiguration file.
Related
we are currently using VSTS to store all our projects.
At the start, we decided to put every work into the same project, and split them using area when creating epics, pbis etc. For multiple reasons, we have decided to split our work into different project that now represent clients.
Moving the cards is quite painful, because the option given only moves the card to a given sprint, and do not move the parent cards or the child card. For exemple: I'm moving the PBI1 from the project ACME to the project EMCA, both have the same number of sprint, EMCA is a duplicate of ACME in that sense. The problem is when moving PBI1 in ECMA, all the child tasks stayed in ACME.
Is there a better way to transfer all my work to the new project?
Thank you
One way to do it is to connect VSTS to Excel to make the transfer.
Marketplace Add-in VSTS Open in Excel
Once you have done that, you can Save your original Project's Epics, Stories, etc. in Excel format.
Then open your other Project and Insert your Epics, Stories, etc. from that Excel document.
You can use VSTS Sync Migration Tools, this tool support bulk migration of work items with the links:
LinkMigrationContext - Migrates all the work item links, both
between work items and external links.
There are two ways to use these tools:
Install from Chocolatey
Download the latest release from GitHub and unzip.
Find here the documentation and how to migrate the work items with the links.
I'm relatively new to developing with tfs (only used git before).
I'm connecting to a server, which contains a decent amount of projects.
When I create a new work item, I can select only the server below 'classification' and not the specific project.
How can I allocate a work item directly to a project instead of the server?
Thanks!
You could directly create work item under the specific team project. The simplest and effective way is through web portal.
Project--Work--New Work Item--Work Item Type
After this the a work item directly allocated to this project instead of the server.
In work item, several features depend on the team project or team that
you have selected. For example, dashboards, backlogs, and board views
will change depending on the context selected.
When you add a work item, the system references the default area and
iteration paths defined for the team context. Work items you add
from the team dashboard (new work item widget) and queries page are
assigned the team default iteration. Work items you add from a team
backlog or board, are assigned the team default backlog iteration.
You navigate to your team context from the top navigation bar.
If you are new to tfs work item, suggest you take a look at related tutorial in MSDN: Plan and track your project with work items. Besides in TFS, there is a concept of permission, also make sure your account have enough permission for the project and adding work item.
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
My team is just now starting to use TFS 2015 Update 1 on premise to manage their development process. I have set up the server and defined some custom states and transitions for work items to better map to our process. To start with, we will only be taking advantage of the Kanban board and are not attempting to use iterations for a variety of reasons I won't get into here.
My problem currently is using TFS to plan releases. Specifically, I don't see any way to group Features and User Stories into a specific release. All of my googling has turned up many articles involving Microsoft Release Management, so I installed and configured it, but it is absolutely overkill for what my team is trying to do right now. I'm not trying to automate deployments to different environments at the moment, I just need a way to group work items into a something that encapsulates the concept of a release in TFS. Is there no way to do this? The best I can come up with right now is to further modify the work item templates to either provide a simple "Release" field with a pick list, or define another type of work item that I can group the others into. This seems like a glaring oversight by MS from my perspective, so I'm hoping I'm just missing something.
Grouping work into releases can be done in a couple of ways, just remember that the concept of a "Release Plan" doesn't explicitly exist in TFS. Release management covers the "Release to Production", but doesn't cover any planning.
Ways to plan releases:
One way is to create a Release Iteration, this works when you're not working on multiple releases in parallel and truly finish one release before working on the next. The Release iteration used to be default, but has been removed from the product in favor of teams delivering sprints and teams doing continuous delivery.
Project Root
+ Release 1.2
+ Sprint 1
+ Sprint 2
Another option is to use Tags. You could tag work items with a tag that signifies it's targeted for a specific sprint.
Use a Marker workitem, on the backlog place one work item which clearly stands out ### END OF RELEASE 1 ### Any workitem below it is not part of that release. This technique fits a more agile way of working and more clearly shows that the contents of a release are a floating thing.
Create a custom Release Workitem, link your other workitems to this work item to target it for that release.
And your option to create a picklist on a *Custom workitem field** is another option.
Alternatively you could also use the Area Path in much the same way as Iteration Path. By using the Area Path you have the benefit of not having a sprint tied to one specific release.
It is not the best solution but could be the solution in some cases.
Answering solely based on your question around planning releases, then:
Create a custom work item template, called 'Deployment'.
When planning of a release begins, create a new 'Deployment', let's say, called 'MyProduct v1.1'.
In your planning meeting, create Features and User Stories appropriately, and create a relation to the 'MyProduct v1.1' Deployment, by opening the User Story and adding a Link (using the Deployment Work Item number) as 'Related'.
To monitor Deployments, create a custom Work Item query targeting the new 'Deployment' Work Item template. You can configure this to display on your dashboard.
Follow whatever release procedure you like based on the 'Deployment' and its' relations.
You should follow a naming convention when creating 'Deployments' for consistency.
p.s. I recommend using the extension 'Work Item Visualization' in this instance. It'll nicely map out the 'Deployment' related Work Items.
If you want to use TFS to actually build an and create a Release, then Release Manager is worth considering.
TFS 2015 Update 2.1 now includes a built-in version of Release Manager. It's much more user-friendly and simple to configure when compared to Release Manager standalone installations.
To group work items into a 'release', you can do the following:
Create a build definition for the repository you're working with - see Build Def creation docs
Create a Release definition - see Release Def creation docs
Once you have these definitions created, the working process would be:
Developers work against work items
Commits are made against the WI number (or tasks)
When it's time to create a release, start a build on the definition you created. In doing so, WIs will then be associated with a Build Number.
When the build succeeds, start a new Release from the definition you created.
You have have a set of work items associated with a release, see screenshot:
Note: You can enable CI builds and releases, although the above is based on manual triggers.
You can also directly call the Release API to locate WIs associated with Releases, however you'll need to obtain the actual Id of the release first.
You are currently limited however to viewing these relationships based on knowing the Release. In a real world scenario, it's more realistic to look at a Work Item to see when it was release. To do that, there's no built-in functionality at present, however my own-answered question will guide you - see here.
Additional to the methods explained by jessehouwing there exists also several 3rd party tools which can integrate with TFS/VSTS and provide advanced planning features. See VSTS Marketplace for an overview.
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.