Best practices on using (manual) Excel work lists together with TFS version control

Microsoft's Team Foundation Server (TFS) is my favorite choice for version control, change management and taking care of task prioritizing and bug tracking.

However, there are many small-scale projects, where using all TFS's features might seem too high-end. As I'm working with small and medium business projects most of the time, many projects start small, and end up using Excel as a work list.

This works perfectly fine, and you could use for instance OneDrive to share the workbook with others, instead of sending it via email all the time. However, using the Excel as your project's to-do list requires some thinking, as to best support your development work with Visual Studio and TFS version control.

One of the most useful things in TFS is the ability to link source control changesets into work items, i.e. the tasks you do with your application. When checking in code back to version control, you can link those work items that your source code edits are associated with.

This is highly useful in tracking the changes done, but also when it's time to update your production with the latest application version. In this case, you might not move all available features from development to production, but instead just a couple of new (tested) features. When you know which TFS changesets this affects, you are in good hands.

When using an Excel sheet, you need to create such links manually by hand. This requires that at minimum, you have something to refer to in your version control check-in comments: I would recommend a simple ID number, or a similar short, unique identifier derived from the name of the task.

In addition to this ID number/value, you'd need a couple of other fields. Based on my experience, the following would in my opinion be the minimum:

• Task ID, such as 12345
• Task name, such as, ”Add secure login page”
• Task priority, such as a value from 1 to 100, with lower numbers indicating higher priority
• (Sprint number or name, if you are using sprints)
• Created date, a date when this task was added to the list
• State, to indicate the current status of this task; such as a drop-down list of choices like ”New”, “In Progress”, “Ready for testing”, “Completed”
• Developer’s Name, could be just initials, too
• Date when (last) tested, i.e. also the task completion time
• Comments and more details about the task.

With these eight–nine fields, most of the needs that arise in software development are nicely covered. Of course, your situation might need more fields, such as the name of the tester, how long it has taken to complete a task (for billing purposes), and so on. But if you start at least with the above, things should go in the correct direction.

Finally, a reminder: TFS does support very nice Excel integration, wherein you can fill in TFS work items using Excel. Be sure to evaluate this option before kicking in with your custom Excel solution. Even that said, I often find customers have already started filling their tasks in Excel before the real development work starts, so you might have to work with what your customer (internal or external) gives you.

Hope this helps!