Currently using TFS 2012, we have multiple scrum teams sharing the same backlog and the same iterations. I'm trying to find a way to have a default PBI (Story) appear in each Iteration (Sprint) across all the teams. Is this possible or does each team need to define the PBI themselves in each iteration.
No, not possible. Best method would be to have each team create their own PBI and associate that PBI with the original one.
Related
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'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.
In attempting to understand what I'm seeing in TFS 2012 Web Access under WORK | backlog | Product Backlog, I used the "Create Backlog Query" button and then opened up the new query in the edit to see how it works. I noticed that it displays PBIs that fit two descriptions:
PBIs anywhere under the root iteration (the backlog) in New/Approved state.
PBIs in the backlog (the root iteration) in New/Approved/Committed state.
Why would a PBI fit this second description? Why would a PBI ever be committed in the backlog? Is it maybe some way of maintaining theme- or epic-level PBIs after refinement, and setting them to committed when their user-story-level children are committed to real sprints? Is it maybe just a means to compensate for shoddy bookkeeping where incomplete PBIs are kicked to the backlog but without reverting their states back to Approved? Maybe some other reason?
New - These are PBIs that someone has added to the product backlog and have not been reviewed by the product owner and have not been agreed to build.
Approved - These are PBIs that the product owner has agreed with, edited and made sure they are understandable for the team. Once approved they are ready for the team to pick up in sprint planning.
Committed - A Scrum team has discussed the PBI in sprint planning, created some tasks and agreed to do build the PBI in the current sprint.
Done - In sprint review, the product owner inspects the work the team has done and if he/she agrees it meets the requirements and quality standards, then the item is moved to done.
You're right! From a SCRUM perspective it doesn't make sense to list a Committed PBI in the backlog. The team has either committed the PBI to a sprint or they haven't.
Interestingly - the term Committed is not mentioned in the SCRUM Guide for Sprint Planning or Sprint Backlog.
My guess - Microsoft used the term Committed to describe the Development Team's ownership of a PBI when moved from the Product Backlog into a Sprint, but didn't want to enforce to the rule through validation or automatically changing PBI status.
If your looking for a more authoritative source - there is state diagram article on MSDN which describes the available status points without refereeing to Sprints.
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.