VSTS 2010 in Action Part 2 – Project Planning

Welcome to the latest instalment in my series on VSTS2010 in action. So far I’ve covered the process I’m using, which matches as much as possible the development process I use at work. I’ve also talked about the tools I’m currently using at work, and what I hope to discover about TFS 2010. Check out the previous post in the series here. There is also a full list of all posts in the series here.

This time I’m going to cover project planning. Brian Harry has a good overview of the Project Management improvements in TFS 2010 here, I’d suggest you have a read of this, since he covers some areas you may be interested in, which I’m not going to go into, such as MS Project integration.

Our process begins with some project setup tasks, before development really begins. 

1. Create backlog of user stories
2. Add any predecessor/successor links
3. Define areas and assign stories to each area
4. Rank the stories
5. Estimate the stories

Then, each iteration/sprint we take a selection of stories from the backlog and implement them. Sounds easy huh?

What is a user story? Well, Wikipedia’s definition can be found here, but I like to think of the user story as a way of documenting, from a user point of view, a particular functional requirement that the system must support. So, for example, “As a user I would like to log in to the site, so that I can manage my bank accounts”, might be a user story for an internet banking website. Microsoft’s documentation for MSF 5 is still being developed, but they have some good material on User Stories here.

One of the quirks of the MSF Agile process that came out of the box with TFS in earlier versions is that it used “Scenarios” instead of the more well known “User Story” or “Use Case” for high level requirement documentation, which meant that lazy (or busy!) teams would shy away from using it, because they didn’t have the time or inclination to implement their own custom Work Item type for user story. Well as of MSF Agile v5, which is the agile process shipping with TFS 2010, Microsoft have switched to the “User Story” approach. I’m not sure its actually much different in fact, other than the change of name for the work item type, but it’s more consistent with the terminology that agile teams expect.

Here’s a what the User Story screen looks like in VS2010:

Some points to note about the user story are that there is a title field, which is pretty much the only required field; area and iteration path fields allowing you to classify stories; the Stack Rank, Story Points and Risk fields; the fact that you are encouraged to enter acceptance criteria with the description; and that there are a number of other tabs that support various linkages to other work items such as test cases, tasks and other user stories. I’ll be coming back to this screen to cover my usage of some of these fields in more detail later so I’ll leave it at that for now.

At this stage in the project, user stories should not be too highly detailed, since they are really intended to be a starting point, something to be elaborated upon down the track, when the time comes to implement them.

Now, usually the initial list of user stories will be defined in a workshop or series of workshops with the customer. Because of this, there will be a point at the beginning of the project where you’re going to have to enter a lot of user stories at the same time. You could do this by clicking the “Team” menu in Visual Studio, and selecting “Add New Work Item > User Story”, filling out the form above, then rinse and repeat for each story. But that’s not going to be very efficient when you’ve got a lot of stories to capture. Fortunately you can enter them in bulk through a number of other means, such as from an Excel spreadsheet, or via the project portal.

I’ve chosen to use Excel to enter the stories into my project backlog. Excel integration is not new to TFS2010, so you’ll probably be aware of the excel “Team” add-in that takes care of the retrieval from and publishing to, TFS. I find that the easiest way to establish the appropriate integration is to do an initial “push” from TFS to excel, then make some changes, before publishing back to the server. With TFS2010, there is a ready made spreadsheet that helps you to do this for your product backlog. To find it, open the Team Explorer tool window in Visual Studio, expand the tree under your project, and select “Documents > Shared Documents > Product Backlog.xlsm”. This will bring up the Project Backlog spreadsheet.

The worksheet is pretty self explanatory really so I won’t go into it’s usage in much detail. It also has a tab containing instructions for its use. My project’s product backlog, with user stories all entered, estimated and ranked, is shown in this screenshot.

So the first step is to enter all the stories. I’ve gone through and entered not just the title, but also a description, containing the acceptance criteria for each story. It’s important to include this up front, since the acceptance criteria will ultimately drive your implementation and testing.

In order to be able to choose the stories for the first iteration, we have to have our project backlog sorted into some kind of priority order. Generally we’ll need to consider both the importance to the business and system dependencies or importance when we rank stories. So for example, the customer might consider it more important to have the ability for users to make an order in an e-commerce site than for their internal users to be able to update the product catalogue, but if it really makes sense from an implementation point of view to do the product catalogue first then that would likely change the order of precedence for these stories.

I must admit to being surprised that the User Story work item in TFS2010 does not have a priority field (the backlog spreadsheet has this field, but it’s not present in the User Story work item… :/). So you’ll have to trust me that I did take the business priority of each story into account! Other major factors that I consider when ranking the backlog were the Risk involved in implementing each story, plus each stories dependencies. One thing that also does not appear in this spreadsheet are the linkages. TFS 2010 supports a number of different types of linkage, but at this stage I am most interested in the predecessor/successor relationships.

So I’ve gone through all my stories, and assigned a Risk rating, as well as established the links to predecessor and successor stories for each entry in my backlog. At this point I found it also made sense to assign an Area Path for each story, not just for categorisation, but to help me determine the relationships between each story. You are able to use the backlog spreadsheet to do all of this, except establish the relationships. For this you need to use the Visual Studio tools. You can run the “Open User Stories” query and use the query results pane to navigate between user stories, updating each story as you go in the lower half of the window. The Query results screen has had a bit of a usability overhaul in VS2010 as well, with the addition of buttons allowing you to quickly show/hide the entire results pane, or the entire work item detail pane, and to change between the original over/under arrangement and side-by-side. Below is a screenshot of the result window with the relevant links tab in focus for one of my user stories, showing the predecessors and successors for that story.

TFS 2010 provides a field on the user story called “Stack Rank” which you use to represent the blended ranking of each story. Taking each story’s risk, area path and dependency graph into account I’ve assigned a development order to each item in my backlog, and used the Stack Rank field to store it. So what I end up with is my backlog sorted in the order I should be implementing each story.

Now, I could move on to the next step now, assigning stories to the first iteration. However, first of all I’m going to assign relative sizes to each story using story points. I will explain this in a bit more detail in a future post, but the sizing is important because we can use it to give us a good overview of progress towards project completion, both in terms of burn down, as well as earned value.

So I’ve also done estimates of the size of each story here, from a relative point of view. Note that user stories do not have a field to hold an effort estimate in hours, only the story points estimate. This is because you’ll typically track effort against tasks, rather than stories, and each story should have a number of tasks linked to it. Therefore you can calculate the total estimate hours for each story by adding the effort estimate for all the tasks linked to that story.

So, with that done, we now have our project backlog of user stories, with each story given a risk, links to any successor and predecessor stories, an area path classification, and a relative size estimate measured in story points.

My next post in this series will cover the next step, which is to assign stories to iterations, so we can begin on iteration 0.

Technorati Tags: VSTS2010,TFS,TFS2010,Requirements,Project Planning,User Story,Project Backlog

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!