How to Update a Changeset for TFS

There are many reasons why you may need to update a changeset in TFS. If you need to update the comment, please read the post How to Update the comment after check in.

In my environment, I had to do more than this. I have a check-in policy where all changesets must be associated with work items. If the policy is not met, a policy failure can be seen in the changeset reading

You must associate this check-in with one ore more work items. 

This policy can be overridden, but even if you override it, and your changeset is committed, how do you associate a work item with that changeset?

Here is how.

1. Find the changeset number. You can do this by viewing the history for your project.
2. Now open a work item that you want to associate with the changeset. 
3. The work item template should have a "Links" tab. On that tab, "Add" a link.
4. Set the "Link type" to "Changeset". 
5. In the "Link details" section, set the "Changeset:" value to the changeset number you looked up a few moments ago. You can also "Browse" for it if you don't like the "History" approach I mentioned above.
6. Add a meaningful (or meaningless) comment.
7. Click "OK" 

Now, the changeset doesn't have any policy failures (or at least not related to work items).

Scrum: Accomplished vs. Did, Hidden Impediments?

Think about what you did yesterday and what you are going to do today. You can probably make a list of things. Take a shower, eat lunch, go to some meetings, work on this project, refactor some code, etc.

accomplish 1: to bring about (a result) by effort

Now think about what you accomplished yesterday, or what you are going to accomplish today. You will likely have a different list. Finished reading a book or chapter, got requirements from our customer, verified a bug, etc.

do 3a: perform , execute

In your daily stand-up meetings, be aware of people talking about what they did or are going to do instead of talking about what they accomplished. Regardless of your position on the team (Product Owner, ScrumMaster, Delivery Team member), everyone should hold everyone accountable for talking about accomplishments.

If you have a lot of things to do, where those things don't contribute to your sprint backlog, those things might really be impediments.

Today, I am going to work on the code for the new login system and go to a sales meeting.

Whoa! I hope the ScrumMaster catches this. Is this sales meeting a critical part of the product? Will it interfere with the team's ability to deliver? Is it a 10 minute chat or a 3 hour presentation on something not related to the project? How frequent are these meetings? Was this planned? Perhaps this is a meeting where the employee's manager can excuse the worker from, so the worker can focus on the sprint.

Let's re-do that part of the stand-up in a few different ways.

Today, I am going to start coding the new login system. I have a sales meeting as a blocker. It is going to take half the day.

Today, I am going to start coding the new login system. I have a sales meeting to listen to some feedback from our users.

Hopefully, this illustrates how a different mindset can improve the value of the daily stand-up.