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.
Related
We are using the scrum template for TFS 2013. Product Backlog Items and Bugs are at the same 'level', so they are both viewed on the backlog and tasks are created as children underneath. Why do PBIs have the states: New, Approved, Committed, Done, Removed, while Bugs have the states: New, In Progress, Done, Closed (which is the same as tasks)?
By treating PBIs and Bugs essentially the same, I would expect that they should have the same states. I'm not sure what 'Done' is supposed to mean as opposed to 'Closed'. I find it confusing that tasks and bugs can be marked 'Done', which is not the same as a PBI marked 'Done'.
I want to change the names of the states for the the PBIs, bugs, and/or tasks to use more consistent naming conventions, but I think I may be misunderstanding what the terms mean.
As Cece mentioned, the out of the box states in Scrum between PBI and Bug are similar. You can use witadmin to change the states of your Bug work item type to match PBIs.
Another option is to use the Kanban board, where you can create a set of columns and map each column to a state of each work item type.
I'm afraid your Scrum Process Template has been customized before. In the default Scrum process template of TFS 2013, PBI and Bug do have the same states: New, Approved, Committed, Done, Removed, while Task has the states: To Do, In Progress, Done, Removed.
The following diagrams show the typical forward progression of PBI, Bug, and Task work items used to track work and code defects for TFS default Scrum process templates:
PBI:
Bug:
Task:
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.
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.
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.
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.