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.
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.
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.
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.
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.
Is there any possibility to create a custom Work Item Type in TFS 2010 that is read-only after the first save?
We would like to implement a very simple code review solution based on a custom review work item associated to a changeset.
The idea is that after the work item is created, it can not be altered afterwards (not even by the original creator).
I've tried setting the System.ChangeDate to FROZEN but that isn't supported and unfortunately the first save is also a change, so setting it to EMPTY or READONLY doesn't work either.
Did you have a look at the community solution for code review for TFS 2010 http://teamreview.codeplex.com/
The most complete solution for Team System Code Reviews: a specific work item type and a Visual Studio add-in for a completely in IDE code review experience. TeamReview exploits the advantages of Team System and VSX to reduce waste and surface new business value from code reviews
HTH
Chees, Tarun
You might want to look at the work item type's workflow. You can make changes to fields in both the states and the transitions.
You could try to modify the transition from New to To Do (or whatever the first state is called for your WI).
In those transitions, you can freeze or make read-only the fields that you want to freeze.
Hope this helps,
Assaf.