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.
Related
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're using TFS for our day-to-day work management, but are currently unable to use it for source control - we're using SVN instead.
I would like to nonetheless ensure that all our work items have been code reviewed before being closed, and that any code review actions have been followed up on. Any recommendations on how we can keep track of this using TFS with minimal manual steps?
I am also concerned with ensuring that the code review step has not been skipped, and auditability of whether it has happened and whether all resulting actions were closed off. If I look at a closed task, how can I easily tell that a code review occurred on it?
(Optional) Require that every SVN change refer to a work item number in TFS with the check-in comments.
The work item in TFS has a "LINKS" tab on it. As soon as the code is checked in, another work item of type "Task" (or whatever you want to use for code reviews) should be created and linked to the primary work item on this LINKS tab to request the code review for that work item. It should refer to the SVN revision number(s) that need(s) review.
I'm not very familiar with SVN, but I assume there is a way to have branches that could be used as follows. Maintain a separate branch for reviewed code. Only code reviewers can merge into that branch. The only way code can get in there is if the proper work item in TFS exists, and a code reviewer approves and merges the code for it. I'm used to Mercurial and TFS where merging code is really easy. If merging is not easy in SVN, a different solution may be required.
If the linked task exists on a work item, then you know that the code has been checked in and code review is in process. If the link exists, and the linked work item is resolved, then you know the code review is complete. If the link does not exist, then you know that code has not been checked in for this work item (or at least it's not in the reviewed code branch, and has no intent to be there).
We have decided to edit the TFS workflow to include an extra 'In Review' state after 'Resolved'. This allows us to use the existing task board without any overhead of creating separate review tasks, or having to edit the task title to be 'in review: ....
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.
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
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.