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.
Related
When checking in TFS under Work\Backlogs\Backlog items, any Sprint, I can see PBIs and linked tasks under them. However bugs I noticed are treated at the same level as PBIs, meaning I can never see a Bug under a PBI, but I can see a task under a Bug.
Is this because the understanding is that Bugs are an occurrence after PBIs are marked as "Done" in a future sprint (since all PBIs should have gone through testing until completely reviewed and accepted).
I'm thinking if this is the logic then Bugs in their own right are like a PBI - a new "Problem" Backlog Item lol.
We are getting confused because we at first wanted to see Bugs under PBIs or Tasks to see what the bug is associated with, but because a bug may occur from an assortment of development done in the future, it's treated as independent on the same level as a PBI. Am I understanding this correctly or is there a way to put bug under a PBI\Task in the backlog when viewing (I know you can link it as so, but I mean for viewing purposes in the backlog). Thanks.
You can configure team settings to set your team's preferences for tracking bugs.
To see Bugs under PBIs, you can select the option Bugs are managed with tasks under Working with bugs tab. See Show bugs on backlogs and boards for details.
On the board settings page, you can configure bugs display behavior.
They can be treated as Tasks, in which case they show as children of PBIs, at the same level as Tasks, and are displayed on the sprint board.
Or, they can be treated as Requirements, in which case they are shown at the same level as PBIs and can have Tasks created underneath them.
It sounds like you currently have the latter behavior enabled, but would prefer the former.
This is configurable at the Team level. You can configure one behavior or the other, but not both. This means that for a given team, bugs can either be Requirements, or they can be Tasks. They cannot be Requirements in some situations and Tasks in some others.
Also note that if you've upgraded from an earlier version of TFS, you may have to manually enable the feature, since it required some changes to the process templates that you or your TFS administrator may not have made.
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/
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.
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
We have upgraded our Team Foundation Server 2010 to Team Foundation Server 2012 and are now using the great TFS2012 web access to handle our product backlog, our sprints and our scrum board. And it all works very well. All except this: On our TFS2012 web access I go to WORK and I see my Product Backlog. However I expect only to see PBI that are not assigned to a Sprint (Past/Current or Future sprint). However I see all PBI that does not have status Done. I would expect that PBI are removed from this Product Backlog when it is moved to a Sprint Backlog. Right?
I would like to edit the work-item query to change so that only PBI that has a iteration path not inside a sprint. Can I do that?
There is a button Create Backlog Query and when I click on that a new query is created. I can edit that query - but it is not used as the query for the Backlog/planning screen.
I have not tried to see if this query is like that on a newly created TFS2012 Team Project. It might have something to do with the upgrade from a TFS2010 team project.
Thanks in advance.
Edit Oct 15:
When creating this question I felt it was wrong that a PBI could be both in a Sprint Backlog and the Product Backlog. However - when thinking how the planning is done - this might be okay. I should think of the Product Backlog as a backlog of PBI that are not done. PBIs might be planned for a sprint (current or future or even a past sprint) - however they are not done.
About the forecast feature in the Product Backlog view: There are some issues with this. The backlog priority has higher priority than already sprint assigned PBIs - this could be improved. I think this feature only can be used for a very rough estimate for future sprints. If you have many PBIs in your sprints - the forecast feature might be even misleading. That's my opinion.
There isn't any option to hide work items that are already in a sprint/iteration or change the backlog query. I also checked the TFS 2012 Update 1 CTP that includes a number of enhancements too. I think this would be a very useful feature. I created a Visual Studio UserVoice feature suggestion. If you have any votes available, feel free to vote for it so it will get more attention.
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3257889-hide-iteration-work-items-in-web-access-backlog-or
You need to change the PBI to the appropriate state. Once it has been "committed" to a Sprint, it will no longer be in the backlog.
If a PBI is assigned to a specific sprint and you set the state of the PBI to anything but New, it will disappear from the backlog and only show in the sprint. If you keep it at New, it will show in both.