We are using TFS 2018 Update 2 with a task backlog that is configured to display the bugs as tasks. The problem is that we have like 10 states on bugs, and the names are different of the task states, so our board has too many columns.
I thought I could regroup those columns by defining the element under the item that does not seem to regroup anything. We use the element successfully on PortfolioBacklog and RequirementBacklog items, and the documentation says is available under so I don't really understand...
Any idea how we are supposed to manage that?
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.
So I am trying to write a query that will show me completed bugs, of completed PBIs, that were handled within the same sprint. In other words, bugs we introduced with new functionality, but also closed before finishing the Iteration.
The issue is the hard reference to Iteration Path. What I would like is a variable like #ThisIteration, and I would place it both of the highlighted spots. This way I could return all of the Bugs and PBIs that were resolved with in the iteration for all time.
I assume this just doesn't exist within TFS Queries, so I am looking for work arounds, or clever solutions, like WIQL, etc.
Thanks,
Devin
Based on your requirement: "write a query that will show me completed bugs, of completed PBIs, that were handled within the same sprint"
The query you created should works. For the Iteration Path we can only use the macro #CurrentIteration in on-premise TFS. In VSTS you can use the #CurrentIteration +/- n to offset the iteration. Please see Query macros or variables and Query for items based on a sliding window of team iterations for details.
Note
Feature availability: The #CurrentIteration +/- n macro is supported
for VSTS only, and only when run from the web portal.
Besides, you need to adjust/modify the query based on the Bugs working as.
If Bugs are managed with requirements, then the Bugs and PBIs are
in the same level. So you can use Board Column field to filter...
If Bugs are managed with tasks, then the Bugs and PBIs are not in the
same level. Filter by Board Column will not work. So you need to use State field to filter...
WIQL would be the same...
We're still fine-tuning our ALM process using TFS 2015 Update 1 On-Prem. We are using the standard SCRUM template and we display bugs on the backlog, along with requirements. Bugs are reported by the business and go through the same level of analysis as PBIs in that they will contain child tasks:
Now for PBIs, when a tester is testing the PBI and discovers a bug with it (which needs to be fixed as part of this sprint), they will create a bug as a child to the PBI. This keeps them together on the task board. 1 PBI may have many bugs and these may be worked on by different people. These child bugs will have child tasks.
The process mostly works but on the Kanban board, the child bugs are shown, the parent PBIs are not. Why not? and how can I work-around this? I can link them differently but we want them to stay together on the boards.
Thanks
It feels like you're really mixing and matching the two supported scenarios here.
Personally I prefer not to create Bugs as part of the sprint (to me they're not really bugs if they haven't made it out of the iteration) and often it's used as a communication mechanism instead of dev & test working closely together.
If you want something on the board under the PBI/Bug, you could use a Task Work Item (or a custom type) and then use the funky card colouring on the board to look for a tag to signify that it's an in-sprint bug/issue.
Highlight work items based on custom criteria
In TFS 2013, for every work item (product backlog item, bug etc.) a task has to be created. So every time a bug is created or a backlog item is added, at least one additional linked task needs to be created.
This makes it quite cumbersome to maintain the system. Is there a way to just create one work item that goes from the backlog to being developed to being tested without having to create additional tasks?
Maybe this could be done via a different process template? I’ve tried both scrum and agile build in templates from Microsoft.
There is a new article on MSDN that addresses this, at least for bugs. It shows how to make bugs act as tasks in TFS. You could theoretically expand it for any work item (although I'm not sure this is advisable).
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.