In TFS 2019 we could see a list of sprints/iterations down the left-hand side of the screen. This allowed, amongst other things, people to move work between sprints relatively easily by dragging-and-dropping bugs/tasks/stories.
Azure DevOps has replaced this with a drop-down from the Sprints section, to navigate to a different sprint. As there is now no list view, it makes it harder to move work around.
How do we now see a list of sprints/iterations, to assist navigation and to restore the ability to drag-and-drop work into other sprints?
../_sprints/directory only shows Teams and the Current sprint, it doesn't show a complete list of past/present/future sprints.
The way to do this is to split the iterations into Teams. You would/could create a Product or Project team, and then assign iterations and/or areas to that Team.
From the Sprints page, select your Team from the top-right drop-down, which will then narrow down the list of sprints to select from. Navigating to the Backlog sub-page will then give you the other iterations in that Team on the right-hand side. You can drag-and-drop work items from an iteration into another iteration for the same team from this list. The target iteration will show a green border when hovering the work item over it.
Note: I would add screenshots, but the content is company-sensitive.
Related
Background: A person I work for has her TFS set so that her ToDo, Impeded, InProgress, and Done columns show two items wide in each. The number of tasks has mushroomed recently as management wants to track work at a finer level of granularity.
I'm thinking this is an individual option set (or loaded) on her PC. I've gone through as many of the configuration options that I have access to. This might be something that she has special rights to (she is an software development manager and I am just a scrum master)
Microsoft Visual Studio Team Foundation Server Version 16.131.28106.2
Question: The standard view I have had in TFS and Azure DevOps allows for a single item in each column. What do I change/load/configure/sacrifice in order to get a two wide listing in the columns on my work board?
Thanks for any ideas, help, etc.
According to your description, it seems that you want to Split columns on your Kanban board to show work in progress.
In your Boards >> Setting >> Columns. Enable the Split column into doing and done to make the columns show two items wide in each. Please notice that, you can’t split the first and last columns(To Do and Done). Since they are always mapped to the initial and last state.
I have two project setup, both using the Scrum template. In one of them the sprint backlog board shows swim lanes/columns as I would expect:
To Do
In Progress
Done
In my other project (the one that matters, of course), it looks as if the columns from the Backlog Items have been merged with those of the Sprint Backlog items and displays with all of these columns:
To Do
New
Approved
In Progress
Committed
Done
The extra columns appear to be read-only in the board view and do nothing but make the board cumbersome to use. Have I changed a setting somewhere that affects this?
You probably have one team (or project) configured to have bugs on the backlog as requirements, and another team/project configured to have bugs on the backlog as tasks.
Bugs have a different set of states, so if you treat bugs as tasks, the board will show two sets of states: One for bugs, one for tasks.
This can be configured by going to your team's settings (click on the "gear" icon on the top right in VSO, then Overview tab, then choosing the team and looking at the settings).
Daniel's answer pointed me in the right direction, but it still wasn't clear exactly what steps to go through to fix the issue. Here are step-by-step instructions on how to set the number of columns on your sprint board based on how your team works with bugs.
Note that this is a modification from my original answer. The way to fix this has become dramatically easier after the latest update to VSO.
Click the gear to edit settings on the sprint board:
Click Working with bugs under the general heading in the left column.
The option you select here determines how many columns appear on your sprint board.
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.
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.