We've recently added a new workflow state "Released" to both our product backlog item (PBI) and bug templates. Unfortunately, when a PBI or bug is marked "Released" it no longer appears in our default sprint queries. Is there a way to change the default sprint queries so that this new workflow is included? We're using TFS 2015.
Any help would be greatly appreciated!
You cant modify the Query, but you don't need to.
You do need to add that new State to the Process Configuration so that TFS knows what to do with it. You need to mapp the new state to one of the meta-states; "Proposed", "InProgress", or "Completed".
https://www.visualstudio.com/en-gb/docs/work/reference/process-configuration-xml-element#map
Once you have added the map work items should appear on the relevant board.
Related
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.
I am using Visual Studio Scrum process template and TFS 2013. Is there a way to define a checkin policy that would constraint developers to always use a Task item to associate with their changesets?
I have seen developers associated their changesets with PBI and Bugs without creating any Task items for those.
Yes, you could do it be defining a Work Item Query Policy.
Here is an example:
Create a new query like this (could be more advanced if needed)
Create the check-in policy and choose "Work Item Query Policy" and choose the query you have just made
If you now check-in you will get the warning that you haven't associated any items from that query - in this case, any tasks
I hope that was what you were looking for :)
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.
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