Maybe I am not understanding the scrum development model correctly, but I am confused why TFS places bugs on a different row than my backlog item even if the backlog item is set as its parent.
I thought that we would make a bug report, and it be placed in the TO DO column. Then as you commit code to that bug, you associate the commits with that particular task ID for the bug. Then once it is done it is moved to DONE. Is that not how scrum works? What is the typical process for fixing a reported bug?
That is the view of the task board. In the most recent Scrum process template (Microsoft Visual Studio Scrum 2.x), the Bug is in the Requirements category. Doing so, the Bug is treated like a Product Backlog Item (it can be stacked ranked, broken down into workable tasks, and fed through the process like any other PBI). If you are on TFS 2012 Update 1, or TFService, you should have a Kanban board tab on the product backlog page which is where you would move your bugs through the states (New/Approved/Committed/Done). In the task board (screenshot above), the Bugs and Product Backlog Items will be shown as rows (where you have Task Here and Bug Here) and the the tasks will exist in the To do, In progress, and Done columns.
When you work against a bug, you work specifically against the tasks, and associate/resolve those tasks as you check in code. Once your 'Definition of Done' has been met, you can then move the Bug work item (on the Kanban board, or manually via the state field) to Done.
We are developing agile tools for TFS since 2008 at Urban Turtle. In the 2012 version we did exactly what you are looking for. Green line represent User Story (PBI) and red box represent bugs.
You can try our Product online if you want.
This is a print screen of the feature you requested. If you need more info just contact me. ddanis#urbanturtle.com
Related
I'm working with TFS 2015.
The thing is that my team has got a Feature. Inside this feature we have several backlogs. My teammate is working on backlog X. His backlog shows on the task board.
How to do this ? I can only add tasks from feature view.
Features page
Task board page
Should I add a new backlog in the task board view and then link this feature as parent? But how exactly should it look? I need instructions step by step.
Thanks in advance. :)
In case someone will have similar question in the future:
You have to change iteration path in the backlog to have it shown on the task board.
When I refresh the Backlogview of our TFS 2017 (but the Issue was there with TFS 2015 as well), there are some Product Backlog Items, which are unfolded, showing the contained work items.
This somehow messes up the shown forecast. If I close those PBIs so that their WIs are no longer shown, the forecast disappears is not shown at all.
Is there something I might be doing wrong?
You doesn't do anything wrong and I tested in both TFS 2017 and TFS 2015 to confirm your issue. It does show like that.
This issue happens in the following situation:
Look at the pictures below, I have 2 PBIs that has child tasks. When I fold 'mmm', the 'Sprint2' forecast line won't disappear. When I fold 'jjj', the 'Sprint3' forecast line will disappear. It is hidden together with the 'Task2' under 'jjj'.
After fold:
As a workaround to solve this issue, you could drag workitems like 'jjj' to other place. Change the order of it. Do not let workitems who have child tasks show above the Sprint forecast line.
I need to set a default value for the Retrospective tab in TFS 2015.
Factory value is the following (TEXT 1):
What worked?
What didn't work?
What will we do differently?
Using the Powertools, I add a DEFAULT rule. In the rule i specify the following default value for the Retrospective (TEXT 2):
What worked?
Please check out what you wanted to do differently in the last two sprints.
What didn't work?
What will we do differently?
So really it's just adding Please check out what you wanted to do differently in the last two sprints.
Now here comes the problem. I save my work, and if I create a sprint in Visual Studio, TEXT 2 is displayed.
If I create a Sprint in Online TFS (accessed from browser), it will show TEXT 1.
Did anyone have a similar problem in the past?
Thank You in advance!
The Sprint work item, used in TFS 2010 with the MS Scrum 1.0 process template, was removed from the Scrum process template 2.0 of TFS 2012.
However since TFS 2012, you configure the sprint schedule as part of the new Agile Planning feature, making the Sprint work item redundant.
So your options for storing the goals\retrospective:
Use a Task work item (Title, Description fields)
Add custom field in the Product Backlog Item
Use SharePoint integration - store as a document
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.
We recently upgraded to Team Foundation Server 2013.
We have heavily customised the standard MS Scrum template so that we have different states from the standard Scrum template.
In the process configuration for the backlog items, you map each state to one of three metastates
Proposed
InProgress
Complete
These metastates then drive how your backlog items appear on the backlogs and also directly affect how the velocity is calculated for each sprint.
In TFS 2012, we were able to map multiple states to the "Complete" metastate, which meant that we could consider work as "complete" and show as so in the velocity chart, but still keep the work item in the backlog (particularly useful for tracking the QA and Release process after developers have actually "completed" development)
For some reason in TFS 2013 this has been changed so now you can only map one state to the metastate of "Complete" - try to do otherwise and you are met with the error message below
The following element contains an error: RequirementBacklog/States. TF401099: This element defines the states for work items that appear on your backlog. The state configuration is incorrect. Each work item on this backlog must have one state with the type 'Complete'. The following work item type has multiple states with the type 'Complete': Product Backlog Item.
I would like to know if anyone else has been able to get around this issue, by somehow customising TFS to allow multiple complete state mapping?
I realise this is of limited use so long after the TFS 2013 upgrade but I just came across this issue myself and fixed the problem it was causing me.
I have an old project that was previously upgraded from TFS 2012 to 2013. Trying to access the backlog resulted in the "Each work item on this backlog must have one state with the type 'Complete'" error reported above.
The process configuration (exported using witadmin exportprocessconfig) had states defined that included the following two:
State type="Complete" value="Released"
State type="Complete" value="Removed"
Unfortunately TFS 2013 only allows one state with the type "Complete" so we couldn't have both of these states. I initially tried changing the type of our "Removed" state from "Complete" to "Proposed" but the items were then displayed in the backlog rather than hidden.
After a bit of searching, I discovered that the "Removed" state is now built-in to TFS. This MSDN article shows four states in the process configuration xml file and points out the process also includes "a fifth state, Removed, to account for a state removed from the backlog without being implemented."
The steps I followed to fix this were:
Add a new temporary state "ToBeRemoved"
Move the "Removed" items into the "ToBeRemoved"state
Delete the definition of the "Removed" state from the process configuration file and call "witadmin importprocessconfig"
Move the "ToBeRemoved" items back into the "Removed" state.