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.
Related
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.
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/
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.
I have setup Jira and Greenhopper and set up an initial sprint. I have mostly done scrum during my years via a whiteboard and face-to-face communication. I wonder how I should handle unplanned items using greenhopper? I don't just want to add a New Card and have it screw up the statistics. Would be nice to be able to get a figure of the ammount of unplanned work when the sprint is done. My initial guess was to add a New Card on the Task Board and tag it as an unplanned. But I don't seem to find any unplanned tag for a Card.
I've been using Greenhopper for about 1 1/2 years. It works pretty well and is invaluable to our team but isn't a substitute for post-its on the well for the daily stand-up. Over the 1.5 years, we've ended up collecting a lot of tasks, bugs, and other items in Jira that aren't immediate backlog items. Managing them is the most difficult in Greenhopper. These are the Unscheduled items.
I have these versions set up in Greenhopper:
Unscheduled: this is a holding pen for a few hundred items that we may or may not ever get around to. Some are ideas, some are bugs that we can't fix at the moment.
Unscrubbed bugs: as we find new bugs that aren't related to the current sprint's work, they go in here. Every week or so, we go through them and place them in one of the other versions.
Short Term Roadmap: stuff we'll get to soon but not in this or the next sprint.
Sprint Planning: this is the backlog we work from during planning. It's the higher priority items.
v2.3 - Sprint 2 (or whatever version/sprint we are currently working): This is the sprint backlog.
During the current sprint and before our sprint planning session, I organize the backlog and place the high priority items in Sprint Planning so we will get to them next. After the meeting, we place the items we sign up todo into the v2.3 - Sprint 2 and them manage it on a daily basis.
I think when you say 'unplanned items' you are referring to critical 'hot fix' tasks that need to be done ASAP. In my group we use a split team. We have one team that commits to the sprint. The Core Team. They are the only resource we calculate on to determine the amount of work we can do in a sprint. Another, much smaller team called the Firefighter Team is set aside to work on unplanned, critical items that, for example, might be needed in the next release.
We track these side-by-side. The Core Team is NEVER permitted to work on a hotfix item. However, the Firefighter Team is permitted to lend their skills as 'servants' to the Core Team if they do not have any critical items at the moment. Our split on one project is typically 4Core/2Firefighter. We rotate the Firefighter members each sprint, taking care not to remove someone from the next sprint that is in the middle of a big project spanning multiple sprints. So far so good. The only issue I have right now is tracking what amounts to parallel sprints in a meaningful way. I'll tackle that when it becomes a real issue.
See my feature request to Atlassian and Vote for it.
"As a Product Owner, I want new PBIs quarantined from the Backlog until I rank them"
https://jira.atlassian.com/i#browse/GHS-11139