So basically, at my workplace we are going to be changing the regular "states" that are in the agile iterations/sprints in Team Foundation Server 2015. We are going from the states "New, Active, Closed" to "New, Coding, Testing, UAT, Done". The WIT for tasks will be edited to reflect the new workflow, and the process config file will be edited to reflect the new states that we are adding/editing. My question is, are the new states that I've added going to be in the reporting automatically? Or, is/are there other step/steps that have to be done for the new states to be included in reporting?
Just wanted some input from others that have done custom states in their iterations for tasks as well.
Thank you.
Just tried to customized a State "Verify", manually processed the Warehouse and AnalysisDatabase, and checked in the PivotTable in Excel (Selected workitem State and Reason), the custom State sat there as expected:
So, if the process of customizing State is correct, you'll have it in Report without customizing Reports.
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.
I am working with a team and have set up Team Foundation Server 2013. We have a number of tasks that we want to include for each PBI. This includes items such as Code Review, Technical Documentation, etc.
I am looking for a way that these can be created automatically to save time during our Sprint Planning sessions. I am happy to write a UI or console application to do this, but wondered if there is a better way of doing this.
I know that automatically adding tasks might not be the best way to do things, but these tasks are needed due to requirements that have been placed on the team and will be kept to a minimum.
Create a server side event handler which listens for PBI creation and then creates the linked tasks.
Essentially you are creating a class that implements ISubscriber with a method called ProcessEvent which will do the creation and linking of the task Work Items. Drop the dll into:
C:\Program Files\Microsoft Team Foundation Server 14.0\Application Tier\Web Services\bin\Plugins.
Simple article to follow (2012 but concepts are the same in 2013)
Shai Raiten has a good (albeit a little old) blog on the TFS API to implement ProcessEvent.
TFS API: Create Link Between Work Item
You can create the server side events for this as rerwinRR suggestions, but you can also create a work item control that does this work to stay more in control when these tasks are created.
In Team Services (the cloud version of TFS) we already allow you to create extensions which even better support that model of adding actions.
Another option is to use Excel to quickly create these tasks.
I defined new work item with tfs power tools on tfs 2012 server.
new work item name is cab. states: new, active, deployed, closed.
I linked (releated) two User Story to cab work item.
I want to automatic state change(closed) which linked user story when cab work item state changed(deployed)
how to? c# coding? tfs event service? workflow action? or any way?
I don't found article for this requrement
You cannot do this with pure WorkItem workflow.
I would use a Server plugin to trigger event. See this design.
Only downside is that you have to remeber adding and configuring this plugin on every AT node and after upgrade/migration of TFS.
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.
I have a list of bugs in Excel (exported from an in-house bug tracker). These are in various states - active, deferred, resolved etc.
I am able to use the 'Team' menu -> New List in Excel and map my columns. But it seems to work only for new items. If work-item type is 'Bug' then state can only be 'Active'.
This is no good for old work-items that might have state as resolved and need to be imported.
Any suggestions?
Thanks.
The possible states are defined in the process template. As far as you didn't mention your process template I guess that you have a process template where new bugs can only have the state active.
To import "new" bugs with different states than active you have to change your process template to allow the creation of new bugs with any state as start state.