We are using TFS 2015 together with the CMMI process template and I have just found out that Issues do appear on the backlog if they are a child of a Feature or a Requirement work item type. If the Issue is standalone (has not link to one of the two mentioned work item types) it is not visible on the backlog.
I guess that someone has made some hacks here in order to make this possible. Originally, only Epics, Features, Requirements, Tasks, and Bugs should appear on the backlog.
I have checked the Issue work item type definition as well as the processconfiguration.xml and the categories.xml which look quite ok from my point of view.
Are there any another places where one could define which work item types should be visible on the backlog?
Thanks a lot for giving support.
To add a WIT on backlog, the three files below need to updated:
WIT Definition
Categories Definition
ProcessConfiguration Definition
You can check the required changes on this link: Add work item types to backlogs and boards to see if these changes had been applied on your project. If yes, revert these changes, then the Issue should disappear from the backlog.
You should not use the "child" link to associate with Issues.
The Parent/Child link is used for the backlog and I would think that the Issues are appearing because of this.
Try changing the Parent/Child link to Related.
Related
I'm using TFS 2015, with Scrum process template.
I noticed that some backlogs are not displayed using menu 'Backlog' or 'Board' and are just displayed on query or search.
I'm sure that it is not related with a specific iteration. I got experiences this issues sometimes.
It makes me missing some backlogs when I organize the backlogs.
Can I get an information to solve this situation?
I'm sure that query is no problem, however some managers want to use without doing something.
For example:
normally, The backlogs are displayed as follows.
backlog: #1234 (child:#5678
bug : #5678 (parent:#1234)
However, In this case, #5678 is just displayed and #1234 isn't.
so, I have to query to see #1234 or search on #1234 If I want to see.
I hope there are displayed all backlogs on TFS normally.
Please make sure you have enabled the Show Parents and expand the tree hierarchy on the Backlog.
UPDATE:
You need to clarify your question. What's that mean for "backlog" you mentioned here? a PBI or just a bug?
If you can not see the Parents wits, then you need to enable Parents: Show.
If you mean the Bugs can not be displayed on the Backlog, then you can set the Working with bugs in SETTINGS just as you mentioned.
If you mean you cannot see other Backlog navigation levels, then just select the specific Backlog navigation level in SETTINGS- > General -> Backlogs -> Backlog navigation levels
Using Visual Studio Team Services (Online version), I would like to have a simple display for my "Backlog" and "Board" :
Features
Tasks
Bugs
That's pretty much it. I don't want to do anything with, iterations, sprints, user stories, etc.
This is just a one man project and I'm just wanting to see all thing on the backlog/board so I can better manage the project.
EDIT:
Biggest issue I had with this...
My project was setup to use the "Agile" process. I decided to try Scrum process instead and found this to be the deciding factor.
Once a project is set as Agile/Scrum, it cannot be cahnged... So, I Made a copy of "Scrum" process, named it "Scrum_custom", created a new project using this method, then just git pushed my existing project code to the new one.
I marked Daniel Mann's answer as correct seeing as it's what I ended up doing after changing to Scrum and it seems to be working just as I'd hoped!
Just in case anyone else reads this and is looking to do something similar, I would recommend this route...
Under your team configuration, you can change the backlog levels you use. In your case, you want to turn off PBI/User Story.
https://www.visualstudio.com/en-us/docs/work/customize/select-backlog-navigation-levels
Alternately, you could just use PBI/user story instead of Feature. They're the same basic thing except with different names; it's purely a hierarchy thing:
Epic -1 to many-> Features -1 to many-> PBIs -1 to many-> Tasks
Bug behavior is configurable; they can either be treated as requirements (at the same level as a PBI) or as tasks.
If you link Task and Bug to Feature as child, you can manage them in Feature Backlog, but not Kanban board.
To link them as child, you can open a work item > Links> Add link>New Item>Select Child link type.
Currently we are using TFS (Web Version) as we know a product backlog item can be added via 1-Product backlog Item 2-Bug (We are using Bug to keep track of Customer/partner logged bugs)
When ever we post a bug from MTM its visible in the product backlog list (Which we don't want)
Is there any alternates for this?
Can we create one more menu under the Backlogs tab?
enter image description here
You should really create a separate work item type, maybe "Issue", to represent an externally reported issue.
You can then triage those issues and break them down into Bugs and PBI's that then appear on the backlog for ordering.
Try and avoid the Bug as a task Anti-Pattern: https://nkdagility.com/avoid-bug-task-anti-pattern-tfs/
However you can also configure TFS to treat Bugs as Tasks, and thus they never apear on the board. Go to the Backlog and click the lower cog to configure this.
You an then create a custom "Issue" work item type for the reported stuff and add it to be shown on the Backlog.
You will need to edit the process template for this.
In TFS 2013, how do I mark a work item as blocked - at least at the task level, but more preferably any work item. In other sprint tracking systems it's as easy as right clicking on a work item and selecting "Blocked" and giving a reason. In TFS this doesn't appear to be so straightforward...
We use internally a tag called Blocked, and then use the Styling of the board to color the tag Red. That coloring only works on the board, and doesn't show up in queries or on the backlog, but since we use the boards during standup it works wonderfully well.
We have a story on our backlog to create a real Blocked scenario, and is also tracked on User Voice: http://visualstudio.uservoice.com/forums/330519-team-services/suggestions/2717759-visualize-blocked-task-in-task-board.
TFS relies on a flexible process model that can be customized. Out-of-the-box, there is no status Blocked in the available process models. You can customize your work item templates (tasks or others) and introduce the new status and the required transitions. After that you can set the state of your work items to the new state Blocked and set up the required queries.
See this link for a description on the available customizations.
I'd propose to apply the changes to a test environment first. Please note that changes to the work item templates might result in problems when updating your installation. See this link for details.
Interestingly, this is available in the Task work item in the CMMI template. Just copy and paste the xml from the that work item into your Scrum Process Template. Its reference name is Microsoft.VSTS.CMMI.Blocked.
In TFS (2010 and up at least), we have the concept of iteration, which seems to be supposed to help assigning work (what do we do in release 1.0, what is planned for 1.1 and what is left in the backlog). I have to mention I've been looking at the Scrumm template for TFS2012.
Now, how do you classify bugs by product version?
For example, imagine we have the a product with v1.0 and v2.0 in the wild and v3.0 in developpment.
Now, we discover a bug in v1.0, and it turns out v2.0 and v3.0 also contains the bug.
Code-wise, we'll correct the bug in dev, then merge it to v1.1 and v2.1 so that our current users are not left in the cold with their version (because we cannot always mandate upgrading to the latest version).
When creating a bug in TFS, we have the option of indicating an iteration path. But we can only use one iteration, whereas we need to be able to declare the bug as existing in all three version, and mark it as corrected independently as the merges happen.
Is there any way to support that way of working in TFS, or am I looking at it wrong?
One way to accomplish this would be to modify the default Work Item Type for Bug in TFS:
In VS 2010, open the editor by choosing Tools > Process Editor >
Types > Open WIT From Server from the main menu
In the Select Work Item Type dialog, expand the Team Project
that you would like this template to apply to, select Bug and
click OK.
When the editor opens, you'll see a list of all available fields for
the Bug work item. You should notice a Found In field
available in the list. By providing the version number(s) in this
field, it should be pretty easy to write queries that can find bugs
by version.
To display this field, choose the Layout tab to bring up the
form editor. It's basically just a big tree view. Expand the group
for Group - Classification (or wherever you think this field is
most appropriate), right-click Column and choose New Control
In the attributes panel, choose Found In for the Field Name, and
also update the label.
Choose Preview Form to test your changes, then save and close
the editor
There are a number of ways around this, depending on how you choose to approach it. One is to not use the standard Areas field (Mike C suggests a good alternative). Another is to create work items to more accurately reflect the state of the work you're doing. What I mean is this:
If you're releasing a fix across three different versions of your software, I'd assume that you'd want to test it against all three versions to assume the fix is consistent across all of the codebases. A fix that worked in V1.0 may not work the same in V3.0 because the surrounding/affected code may be different.
At some point in that process you could therefore have three separate (but linked) representations of the bug: maybe three copies of the bug itself, or three test cases (one per version that the bug should be tested on) all linked to the original bug. Then, if the bug is fixed in V1.0 but requires more work to be fixed in V3.0, your work items accurately reflect this.