Project Tracking with Team Foundation Server 2010

Microsoft recently released the second public beta preview of the 2010 release of it’s developer toolset, Visual Studio. A key plank in the Visual Studio 2010 story for development teams is their Application Lifecycle Management tool, Team Foundation Server (TFS).

With this release, Microsoft have made some significant changes to the way in which TFS supports project management, particularly with respect to Agile projects.

With TFS 2010, Microsoft have decided to place all the Process Guidance documentation online instead of embedding a copy of it in each individual project’s portal site. So, rather than just duplicate Microsoft’s content here, I’ll provide links to it from relevant points, and instead attempt to provide my own interpretation of what it means, and how to use the process.

I’m not a Project Manager, nor a process expert so why am I writing about this?

Ok, so I might not be a Project Manager by trade, nor am I PMP or Scrum certified or anything like that. What I am is someone who has a spent many years in software development, over a range of platforms, and leading projects both large and small. Over my time I’d like to think I’ve learnt a thing or two from my experiences.

This is my attempt to take what Microsoft are doing with Visual Studio 2010 and describe how I think it should be used. What I like, what I don’t like.

I’m learning as I go with these products, just like everyone else is. I’m hoping to gain a better understanding of the practical application of these new tools as I go. I’m also hoping that by sharing my experiences along the way on this blog, and with a bit of luck, it might just help you to use VS2010 and TFS better too.

What am I going to cover here?

Right, with that out of the way, what am I going to cover here? Well, lets consider the make up of a typical software development team. Over the years, I’ve worked on a range of projects varying in both team size and project scope. I once spent 18 months or so working on a project which only had .75 of a full time person employed on it. Bizarrely, I wasn’t the only person working on that particular project!

I’ve also been involved in projects that have involved upwards of twenty people, spread across 6 separate locations, in three different countries. But the one thing they all have in common is that the roles on the project can be broadly categorised into about 4 groups.

• Project management
• Business representatives
• Developers
• Testers

That’s not  to say that, for example, if you’re a tester you won’t be interested in the developer information however. But I am going to focus on the day-to-day uses of TFS for each of these team members.

It’s worth noting again that I’m talking here about project tracking with TFS, so I’ll be writing specifically about those aspects of TFS that relate to each of these roles with respect to progress through a project. So the features I’ll be discussing in this series will centre around work item tracking, reporting, and planning features.

First up, what is there in TFS2010 that will mean that Project Management will want to use it?

VSTS 2010 in Action Part 1 – Introduction

As mentioned, I’ve been playing with VS and TFS 2010 beta 1, and since I have a personal project that I can use them on, I’m going to cover my adventures in a series of posts.  

The way I plan to run my project is to follow as closely as possible the actual process we use at work, since one of my goals is to find out how well TFS 2010 fits with our current process out of the box, and to figure out where any gaps might exist. Once I’ve worked that out, I’ll also consider how we might close any gaps, be it through a custom process template, custom or modified work items, custom built reports, or whatever it might be.  

By way of introduction, It would be useful to first cover our current tools and our current process. This should provide some background on where I’m coming from with this, and hopefully provide some insight on a couple of the issues that I think are present in our existing toolset in particular.  

Current tools

Currently we only use a subset of the functionality in TFS 2008, as we have other software that we use for things like Project Tracking, and team collaboration. For better or worse, I’m going to work through my project in this series whilst making use of the entire TFS toolset, since my personal belief is that by doing so we’ll get better value for money, as well as enable some key code quality and engineering practices that we currently are not able to perform.  

Our current toolset includes a Software as a Service project management/tracking tool called Rally, which has a really nice user interface and supports a variety of different approaches to agile project management. However, since Rally sits not just outside TFS but outside the firewall, there are some interesting problems we face with it.  

We are, in my opinion, also hamstrung by the fact that we cannot link user stories, defects, tests, etc to items within TFS source control, meaning that we lose the benefits of traceability that an integrated solution offers us. That said, Rally does have a good open API which we can, and do, use to integrate with TFS.  

However, these integrations have to be built by hand, which means someone taking the time to build and test them, and we just don’t have the time to do that. Add to this the fact that the API changes periodically, meaning that we run the risk of having our integrations just stop working suddenly. Add to this also the fact that any outage in connectivity at all means you lose access to the tool, plus the additional license cost (which is considerable with Rally, I’m told), and you begin to see why I’m keen to see whether we can get by with TFS instead.  

As I mentioned, we currently use TFS 2008, but only for Version Control and build. We have one or two projects that make use of the SharePoint integration for collaboration but by and large, projects instead use a Wiki for collaboration, with document storage done on the file system. The Wiki tool we use also incurs a license cost, so I’m planning to evaluate the experience of using the wiki pages built into the TFS SharePoint templates, whilst also using the project portals for document sharing.  

Our current process 

Without going to great lengths explaining our current development process, I’ll just say that it takes elements of SCRUM, and throws in bits of a couple of other methodologies as well. We generally describe our requirements with User Stories, and elaborate on these by adding tasks to them. Our PM practice lead is keen on 2 week iterations, which I find a little short, but not too bad.  

At the start of the project we’ll have a workshop with the customer to outline the user stories, so come iteration zero we will have some idea of what we’re aiming towards. We’ll also have the list done in some sort of priority order, so we also know which order we should be tackling the stories in.  

We’ll typically start with an iteration zero, which we would use to do project start up, as well as perhaps a prototype or proof of concept for the project. This is one area I’m looking at doing something a bit different with my project, but I’ll talk about that in a later post.  

Prior to each iteration we’ll do a planning session where we size the user stories using story points, which is a relative sizing method. Again, more on this in a later post. At the planning session we’ll take the stories from the top of the backlog, and estimate the amount of effort involved in doing each one. We take the total number of available developer hours for the upcoming iteration and subtract the hours for each story off the total until we’ve used up all the hours we have available.  

Before we do the estimating for the next iteration, we first do a retrospective for the previous iteration. This gives us a chance to discuss what went well, what didn’t, and what we’re going to do about it.  

The Project 

My project is focused on building a website for a (currently!) fictional business that uses flight simulators to provide customers with multiplayer simulated air to air combat. The website will have a range of static content on it, but also include some content managed areas. Content management won’t be anything too fancy, though, since the aim of the project isn’t to build a CMS, or even a CM enabled website. The site will also include a blog, and an online store, so that people can purchase merchandise online, to help fund the business and get it off the ground. 

In my next post I’ll start actually talking about TFS 2010, beginning with getting my product backlog set up. Specifically, I’ll cover using VS2010 with Team Explorer, the Web Access tool and project portal, and finally Excel to create and manage the backlog.

TFS and VS2010 – play time!

Well, I’ve finally got the chance to have a play with Visual Studio 2010, and so I thought I’d give it a decent working over.  

I’ve got myself a copy of the Beta 1 release of VS 2010 Team Suite edition, plus TFS2010. One of my main interest areas is in the use of TFS, and therefore I’m keen to explore the changes and (hopefully!) improvements in the 2010 release of this, as well as Visual Studio itself. Hopefully I can get a feel for the changes in store for us, since we’ve paid for Software Assurance with TFS 2008, meaning we get a “free” upgrade to TFS 2010 when it arrives.

I have a project that I’ll be working through using VS 2010 and .net 4, and I’ll be using TFS for source control, work item tracking/project management, and build services.  

So I’m off to have a bit of a play!

Managing Requirements with TFS

So, I’ve always felt that one big gap in software development tools generally was that there’s never really been a truly effective way of managing requirements, and tracing individual requirements through to the code that implements them.

Sure there are requirements management tools out there, for example, CaliberRM, but I’ve yet to see a good integrated requirements-to-code tracibility tool.

TFS does have the potential to offer this, with it’s work item tracking features, and the fact that work items can be linked to code changesets, builds, etc. But I’ve not been that impressed with this from a requirements management point of view, for a number of reasons.

 Firstly, the out-of-the-box process templates offer only a single approach to requirements tracking, using scenarios. This means that if you do things differently (Use Cases – similar to scenarios, but not really the same thing, features as part of an FDD process, or just plain ol’ numbered requirements in a word doc), you’ve got to either change the way you do things, or build something yourself to handle your way of doing RM.

However, I found a series of posts by Steve Lange on RM using TFS, which gives a good overview of the topic, from using out of the box TFS for RM, through to coverage of a number of the third party RM tools that are out there now providing integration with TFS. Steve also does a couple of good pros/cons summary tables as well. Read the series here.