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/
Related
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.
As my scrum team does backlog grooming, we typically start with epic-level work, and refine those PBIs into themes and stories as part of normal grooming activities. As a means of structuring these work items, the PBIs that result from refining and clarifying other PBIs are created as child links of the larger items. We implement this process by assigning only sprintable stories to sprints, while leaving their parent theme PBIs in the current release iteration.
We've been slowly growing into the features provided by 2012 after an upgrade earlier this year, and the ability to drag items around in the Product Backlog view in Web Access (rather than manually tweaking priority values) is extremely attractive.
We'd like to use this, but there's a problem: PBIs that have a parent-child relationship, as do most of our planned work, can't be dragged around individually. Instead, each epic appears as a tree in the product backlog, enumerating its children with its own priority range of [1..1000000], and it drags around atomically.
With this in mind, how is this supposed to work? Am I missing something about the features of the Product Backlog view? Are we intended to be destroying our epics and themes as they're refined into smaller PBIs, so that the stories can be scheduled independently?
We've been struggling with the same type of issue. We decided to remove epics and only use stories. Then we tag each PBI with an epic name so that we can easily search and group items when necessary. Haven't really found any better option yet.
I have a question about Microsoft Team Foundation. In Visual Studio, Team Explorer, I can create a new work item. Work item types here are dictated by your team's chosen process template; I'm not sure which process template we're using. In any case, in Team Explorer, when I want to create a new work item, I'm given a list of work item types to select from, among which are "Product Backlog Item" and "Feature".
I noticed a difference between the two types related to the target resolution date. For a Product Backlog Item, this would seem to be dictated by the iteration end date. For a Feature, it's not as clear. A Feature is also associated with an iteration (and iteration end date), however Feature also has a separate field called "Target Date". The mouse hover text for target date is "The target date for completing the feature".
Should I choose "Product Backlog Item" or "Feature" as the work item type for my new work items? What's the difference between the two?
It looks like you are using the Scrum process template. The TFS site has published some very brief information about Product Backlog Items and Features and the idea behind creating a new work item type. http://www.visualstudio.com/en-us/news/2013-jun-3-vso.aspx
The difference between the two comes down to what granularity you want to work with your work items at:
Product Backlog Items are composed of Tasks and have estimated effort.
Features are composed of Product Backlog Items and have target dates.
I have not been able to find any official guidance on when to use Features vs Product Backlog Items but I have created my own guidance which I am basing this answer on... http://www.nsilverbullet.net/2013/06/04/features-help-us-plan-work-better-in-team-foundation-service-scrum-process/
Should you create a Feature or a Product Backlog Item?
If you think/hope that the new work item that you are going to create will fit into a single sprint you should create a Product Backlog Item and then break it down into tasks for your sprint.
If you think/know that the new work item won't fit into a single sprint you should create a Feature and identify all the value-providing sprint sized items (Product Backlog Items) that the Feature can be broken down into and use these when planning future sprints.
[Update 2014-05-19]
Microsoft have published more information on how to use Features and the agile portfolio concept that has been implemented in TFS https://msdn.microsoft.com/en-us/library/dn306083(v=vs.120).aspx
As TFS applies an agile development strategy I think we can say:
Feature = Epic,
Backlog item = Story
The epic contents similar stories.
I had the same doubts as OP and my thoughts has been aligned with #josant answer, which is very reasonable to me.
On the other side I'm using the Hundhausen book[1] as a reference for adopting TFS+Scrum.
He said things like:
A feature is a discrete unit of functionality that delivers value to the user or business. A PBI may be large enough to have several features.
and then:
A feature may break down into multiple scenarios. A scenario is a narrative that describes a workflow or sequence of steps through the feature that exercises one path toward achieving an expected result.
and continues developing these ideas.
To me, Hundhausen seems to be talking about use cases[2], but still I feel his proposal some counterintuitive, neither seems TFS would be guiding to this analysis method orb I found it referenced in the scrum literature I read.
Probably it's just a matter of choosing a convention you feel more confortable with and adhere to it.
[1] http://www.amazon.es/dp/073565798X
[2] https://en.wikipedia.org/wiki/Use_case
A Feature is a Product Backlog Portfolio.
http://tfs.visualstudio.com/en-us/learn/create-your-backlog.aspx
Feature is a level up to 'backlog items'. team defines work as high-level initiatives and breaks them down into features. which further break down and define the work to be done as 'Backlog'.
ref http://msdn.microsoft.com/en-us/library/dn306083.aspx?
As others said here:
Features: Top Level
Backlogs: One Level below Features (a feature is made of backlog items)
Keep in mind that you can LINK work items and you can display them as a Tree List.
So, you can link a backlog item to a feature, and later, you can link a task to a backlog item. Thus, you get a nice hierarchical tree list.
This is how I use it. Under the tool items "Work" -> "Backlogs" both "Features" and "Backlog Items" are listed. I start with features so there are no backlog items at that point. I add the features by selecting Features under the Backlog header and adding the Feature name in the form then saving and closing. To the left of each newly added Feature there is a green + sign. Click on the plus sign and selection options appears. Choose "Product Backlog Items". When it opens type the name of the backlog item in the top field just like in Features. You are creating these backlog items, there is no pop-up. Fill in the other information as required then save and close. After creating the Backlog items click the green + on the newly created Backlog Items. Enter the name of the work item like you did for the Backlog Items and the Features. When adding the work items include the sprint in the iteration field and they will be in the sprint when you open it. None of this is documented anywhere that I could find. I hope it is in sufficient detail.
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