I have just added a custom state to the User Story work items in TFS. However, everytime that the work items are in this new custom state they do not appear in the backlog at the web.
Does anyone know how I can have these work items being shown on the web backlog?
Thanks
Ricardo
I have found the solution to the issue.
Process configuration had to be changed.
Under RequirementsBacklog element the new state needed to be added wht Type="Proposed" as it is not a start and not a end state.
witadmin exportprocessconfig and importprocessconfig were used to update the Project process configuration file.
Related
I am working with the Scrum workflow in TFS (Visual Studio 2017) and the only available value for the state is New when I would be expecting Approved, Committed and Done.
Why are they missing? How could I solve this?
The transitions between the different states of the work items are defined thanks to a specific workflow.
You have to save your work item with the "new" state before being able to modify its state to other states like Approved for example.
You can find more information at this page : https://learn.microsoft.com/en-us/vsts/boards/work-items/workflow-and-state-categories?view=vsts
Seems you have customized your WIT definition file (in you scenario it should be Product Backlog Item.xml file), and removed the state Approved, Committed and Done and transitions from the file.
So, you just need to add them back and set the transitions between the different states of the work items accordingly.
If you only customized the PBI wit definition file, then the simplest way is exporting the PBI wit definition file from a normal team project (with non-customized templated, it will have the state values you needed), then import the file to your current team project to apply the changes.
However if you also customized other things for your process template, then you may need to modify other related things based on your customized process template.
See Import, export, and manage work item types for details.
You can also use the extension TFS Process Template Editor to export and import the wit file.
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.
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.
Is it possible to reset the work item type history that is proposed to a user who creates a new WorkItem query?
We have some TeamProjects that went through two Process-Template customizations including localization and WorkItem form layout optimizations.
With TFS 2015 we're finally moving to the Agile process template. The problem is that somewhere the TFS stores the WorkItem-Types you have ever used and displays them in the WorkItem query designer.
The values in the Work Item Type are mixed both german and english and are picked from all of the past process templates the team project has ever been configured to use.
Is it possible to reset that list and if so, how?
The scope of the query editor is for all projects in a give collection. When you open the dropdowns, it thus shows all work item types in any of the projects in the collection.
In TFS 2015 we have added a checkbox to scope your query to the existing project. This checkbox is off by default because the majority of the queries run in the scope of a project. When the checkbox is unchecked, the dropdowns are limited to show only the states, fields and work item types that are in use by the existing project.
If you don't need these work item types and the work items, you can use witadmin destroywitd to destroys the work item types, after running the destroy command, the work item types will disappear from the drop-down. But please notice this will also destroy every work item of that type permanently without recovery.
witadmin destroywitd /collection:CollectionURL /p:Project /n:TypeName [/noprompt]
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.