Is there any reason to prefer an explicit Backlog area or iteration node in TFS, instead of just using the root node? Does this improve the function of any of the reports or anything? Do either of them them offer easier managability?
I've seen this done both ways, and I'd like to see suggestions about tradeoffs.
Using a different node for area path:
The concept of a team was introduced in TFS 2012. Each team can have their own home web access page as well as their own backlog. Each team may be tied to a specific area path, and you can set their backlog to a specific area node to filter down the backlog queries. You can even connect to a specific team in Visual Studio 2012, so the work items are filtered down in the IDE environment as well.
Using a different node for iteration path:
Teams can break down their iterations into releases. I.e. sprints 1-10 could be for release one and sprints 11-20 could be for release two. This will give you release burndowns as well as sprint burndown. It really depends on how you develop your software and process your team uses.
These are only a couple of examples as the possibilities are endless. You can also tie teams to a different field other than area path and have a centralized backlog which is then delegated out to the teams. Here is a blog post by Martin Hinshelwood on this specific topic: http://blogs.msdn.com/b/greggboer/archive/2012/01/27/tfs-vnext-configuring-your-project-to-have-a-master-backlog-and-sub-teams.aspx
Related
We are using TFS 2012 in which we are having multiple projects.
As far as I know, the board visibility is limited to one project on its current sprint.
Is there any possibility/addin to consolidate the TFS board using multiple projects ?
It's not support to show work items from multiple Team Projects on a single Kanban board in TFS for now.
Just like you mentioned, Kanban boards in TFS are currently associated with an Sprint path (scurm)/Iteration Path(Agile). An iteration path only exists within the context of a Team Project. As such, Kanban boards by their current implementation live only within a Team Project.
As a workaround, you could move multiple projects into the same Team Project and use Teams instead. Then you could use different sprint/iteration paths or area paths to differentiate your work items. Otherwise you need to use some third party tool or sites help you tracking such as Kanban Tool, simply by creating swimlanes on one Kanban board (one swimlane for each project).
https://learn.microsoft.com/en-us/vsts/work/scale/visibility-across-teams?view=vsts
The Delivery Plans extension does what you're looking for. Letting you combine multiple sprints from different teams into a single view.
We have a five-member development team and will be building multiple internal projects in parallel. Upon researching, I find it is best to create one team project, even for our situation, correct?
If so, would you please recommend how to set up proper iterations for the projects and timelines?
TFS question - small team, multiple projects sounds similar to my situation, but I can't seem to get more than one "current" iteration in the TFS Agile process board.
Per team project you can have only one iteration tree (and therefore only one current iteration). You should decide based on how you plan your team resources. Do you want to have only a single backlog for the whole team or different backlogs for each project?
Each has its pros and cons, depending whether you want to use Visual Studio Team Service mainly for planning your team resources or planning your projects.
Using a single team project / backlog
With this approach it is easy to plan your whole team's resources for the next sprint. You can assign people to different tasks in different projects and have a good overview on what the team currently is working on. To assign work items to different projects you can use the area path.
Planning and tracking the progress of individual projects is a little bit harder with this approach since you have the same iteration structure for all projects and also only a common set of tags.
There are external tools which can integrate with Visual Studio Team Service available from the marketplace though, which can help you with planning individual projects.
Using a team project per project
With this approach you have a clear overview of the progress of each project and you can have individual iterations, tags, etc.
On the other hand it's harder to plan your team's resources since you won't have a single backlog and no place to see what your team is working on at the moment at a glance.
You can create one team project and set several child projects in it. With this, you can have the things configured for the whole project and also the child projects. Refer to this link for details: Multiple teams
We use TFS 2013 with the Scrum 2013.4 template. We have one single project defined in a single collection.
This project contains all the backlog items for all different subsystems and their features.
To manage this backlog, we us the Portfolio Management approach.
With witadmin.exe we created another category (backlog level), as explained in this article on MSDN about Portfolio Management, under the "Add another backlog level"-section.
Only instead of "Initiative", our new category is called "Subsystem". Everything is showing up fine in TFS.
We can now categorize backlog items like this:
MainProject
--->Subsystem
------>Feature
--------->Backlog Item / Bug
------------>Task
All works fine, including different views on the backlog, where all the relations are visible
(like subsystems to features, subsystems to backlogitems, backlogitems to tasks, etc.).
The problem is that if we select the backlog of the current sprint (or any other sprint), it shows only
backlogitems and tasks, so it is unclear to which feature or subsystem the backlogitem belongs.
Is there a way to change the default query or output, so that the Sprint Backlog will also show the Features
and Subsystems in addition to the backlog items?
There is not.
Things in the backlog are part of the time limited execution flow and that does not represent sub system well.
You would be better adding a picklist to PBI, bug, and feature that had a list of sub systems. You would them be able to see on the item where it was for.
I usually reflect sub system in the area path and move team to a separate field.
http://nakedalm.com/team-foundation-server-2012-teams-without-areas/
I have two different projects within same Project Collection.
Is it possible to display the bugs of both the projects in same backlog or kanban board.
Currently, you cannot show work items from multiple Team Projects on a single Kanban board in TFS.
Kanban boards in TFS are currently associated with an Iteration Path. An iteration path only exists within the context of a Team Project. As such, Kanban boards by their current implementation live only within a Team Project.
As #Wouter stated, you could move the two projects into the same Team Project and use different iteration paths or area paths to differentiate your work items. This is actually a best practice. The name "Team Project" was actually a poor choice because they a Team Project isn't really mean to be the same as an actual development project. This has led to much confusion because it is not recommended to create a "Team Project" per actual project. It makes reporting and visualization a real problem.
Remembering that iteration paths are a hierarchical attribute, if you move both of the projects into the same Team Project, you can create an iteration path for each under the root and you can then get Kanban boards for each project. The root of the iteration path will also have a Kanban board and this board will be the rolled up board that shows all of the bugs from both projects on it.
I had this issue myself and found a solution when switched to Kanban Tool; simply by creating swimlanes on one Kanban board (one swimlane for each project) and then allowing bugs to be placed in the backlog and further development tasks in the next columns. So I have a complete view across many projects in one board. Happy to share my findings.
If you want to have information from different Team Projects, you can create your own query. By default, the queries limit their results to the current project but you can easily remove this clause. You will then get results returned from all projects you have access to. MSDN can help you get started with creating queries.
However, it sounds you are looking into having data from multiple teams roll up into a single project. This is supported by using one Team Project with multiple Teams beneath it and using features from Agile Portfolio Management. See MSDN: Agile Portfolio Management: Using TFS to support backlogs across multiple teams
"You could create a query for each collections"
OR
"Create a query like this and select the “Query across projects” checkbox to find all workitems in the current collection"
https://developercommunity.visualstudio.com/content/problem/122305/all-work-items-from-all-projects.html
I'm not sure if this is appropriate for stack overflow but we have recently upgrade to TFS 2012 and noticed that your iterations (sprints) must be children of the backlog iteration. While the tool is rigid in that approach, I'm trying to understand if there is a specific Agile [Scrum] process reason to adhere to this or a tooling concern as to why I cannot have the backlog and sprints be under two different parents?
I've never looked at it as a bad thing, as I always found it makes sense. The Backlog contains all PBI's that make up the product or are desirements for the future of the product, as such it's one big list. The Sprints each are a chunck of stories from that list, but they're still part of that list. Since the sprints can be in the past, present and future in TFS, they together form the complete backlog.
Is there a reason you'd want it to explicitly not be a hierarchy?
If that's the case then you can opt to create multiple teams (if needed with the same members) to look at different backlogs in the same Team Foundation Project.