I am using TFS2010 and I have created a bunch of tasks. Is there any way can change Task work items to User Story?
This can't easily be done. The best option would be to copy the existing work item and then select the WI type you want there. Afterwards, you close out the old WI.
Here is a good blog describing the process: HowTo: Changing TFS workitem
Related
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.
Right now my stories in TFS are being completed, but each time I drag to "Done" the task -- and even stories -- are losing my name on them.
This really gets complicated during scrum, when we're tracking yesterday's activity...
If you have so many items that you can't remember which ones for the story that you were working on were yours then you are doing it wrong.
You can change the work item type to stop this happening. Use witadmin to export the work item and then in the Workflow section remove the call to empty the Assigned To field. Then import it.
I would recommend that you test this on another non-production TFS server incase you ness it up.
is there a way to automaticaly close a User-Story in TFS2010 when I checkin my code
with the last open task ?
I do not want to add the User-Story to the checkin with the code.
TFS can't do this automatically, however tools like http://tfsaggregator.codeplex.com/ can.
As previously suggested, TFS Aggregator can indeed easily do this. Just be sure that you actually want to do this, because you might want a human eye to verify that the story is indeed done.
What I suggest is to use the aggregator not for closing the story, but for moving it to a code complete state (or "ready for UAT", or "deployable", or what-have-you), if your tasks do not, in fact, cover everything needed for "DONE" done.
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.
Warning - newbie question....
I had a vision that I could select what workitem I was working on, and when I checked in the code, I could associate the changeset with the workitem automatically.
I'm assuming that:
I would select a work item and state that I'm starting to work on it,
make my changes to the code base as I see fit,
each time a file is checked out, it is associated with the current work item, and
when I check in I can state that I've stopped working on that work item.
Then if I review a work item, I can see what changeset is associated with that workitem, getting the full fidelity of what changes were made for that specific work item.
Is this possible? Is it automatic? All that I have found so far is a manual association of a changeset with a work item.
The order is: make changes, choose pending changes to check-in, select work item, do check-in. You can enable a check-in policy that forces the change to associate with a work item.
Update
With TFS2012/TFS2013 Premium and Ultimate there is a much cooler way, using the "My Work" page. Before you start coding you select a work item from "Available Work Items" to "In Progress". From there you can directly jump to the "Pending Changes" page by clicking "Check In". It is also possible to suspend your work where the state of the IDE is saved.
Demo: http://go.microsoft.com/fwlink/?LinkID=251849
What you're asking for is not a good idea. That pretty much only allows you to work on one work item per team project at a time. If you can do that, then you must be living a quiet life.
Instead, TFS allows you to associate a changeset with one or more work items - when you create the changeset. This makes it easy to see exactly which code changes were made in order to address a particular work item.
It also allows automated builds to be associated with work items, and enables Test Impact analysis. I don't think any of these things would make sense if you were simply associating a work item with the code you assumed you were going to have to change to address it.
Actually at the project level you can enable "require work item" with checkin. This means that the work item be defined first so that you have somthing to associate with when a checkin takes place.