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!

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.

Team Foundation Power Toys saved my life!

…or at least, my Sanity!!

Anyone following my series about our efforts to build a custom process in TFS for our internal teams will know that I’ve begun by tackling the Work Item Type definitions first.

Without a decent GUI for doing this, it’s all XML, angle brackets, attributes and all…so, with 90+ fields, 13 states and 25+ transitions, theres a lot of cutting and pasting involved, to say nothing of the difficulties involved in managing a 1200 line long XML file in a glorified text editor.

However, for those like myself who are neck deep in the vagaries of the Work Item Type definition schema, help is at hand, for lo, Microsoft have released version 1.2 of the Team Foundation Power Toys. Big deal? Sure is, cos new in this release is a GUI ProcessTemplate editor. Having had a quick play so far with the Work Item editors, it looks to be something of a saviour for me at least. Gone is the endless cut-and-paste routine, replaced with a nice (? better than xml at least…) gui editor.

No more continual making a change, importing to a team project, and checking form layout, as it also includes a form “preview” in the editor.

And it’s even got a (DSL?) designer for defining workflow!!

Nice one! On a final note though, I had a bit of a laugh at the “Microsoft Pre-release Software License Terms” that governs this editor….it states “This software is a pre-release version. It may not work the way a final version of the software will. We may change it for the final, commercial version. We also may not release a commercial version.” and also “The term of this agreement is until 31 December 2008, or commercial release of the software, whichever is first.”….so, it might be released commercially, it might not…and if it is, it might be available before the end of 2008, or it might not. Oh, and if it’s not, then your license will expire anyway.

Last time I read a license agreement! J

TFS Work Item Customisation, and the TF26201 error

With the work I’ve been doing defining custom Work Item Types in TFS lately, I came across an interesting problem, to do with TFS’ TF26201 error, so I thought I’d mention it here, along with how I went about sorting it out.

So, having finished the first cut of the first work item type definition, I went to test it, and discovered that some when changing a test work item to certain states and attempting to save, Team Explorer would fail to save in the new state, with an error:

“TF26201: This work item has unsupported fields, or user does not have permissions”.

I googled the error (as you do) and didn’t have much joy. A couple of people found this problem when doing stuff with the W.I.T object model, but I couldn’t find anything about tracking down whats wrong when testing custom work items using Team Explorer. So, to figure out what was causing the problem, heres what I did:

 

1. Edit the work item type definition file, commenting out all field rules in the “To” state, and upload back to server
2. Try saving item to the new state, which should work now, as there are now no field restrictions in place for that state
3. Uncomment all the field rules from the “To” state again, and again upload to server
4. Open work item and try to save as-is, without changes
5. Team Explorer will complain about specific fields, instead of the general error message
    

For the record, the reason I was receiving this error was because I had some fields in a couple of states with “<EMPTY />” rules, scoped to the STATE. Removing these fixed the issue, and I’m going to try scoping these to the a specific TRANSITION instead.

TFS Process Customisation Part 1: Work Item Types

So, as mentioned in my last post, I’ve been working on a project to create a Process Template that covers one of our internal software lifecycle processes.

The first part of this project that I’ve been working on is customising Work Item Types. We’ve got a few to do, and it’s not so much a “customisation” process as a “create from scratch” process, because the work items we’re creating really bear no resemblance to the out-of-the-box ones. To start with, I’ve got over 90 fields to define, up to 13 states and something like 25 transitions to define per work item type…I’ve been wondering why I let myself in for this recently!! J

Still, most of the work item types I need are just variations on a theme, so once I’ve got the first one done, the rest will be mostly cut-and-paste jobs…

Custom Processes with TFS

So at work we’re embarking on a project to implement one of our internal software development processes in Team Foundation Server/VSTS.

There seems to be a ton of documentation on how to do everything we need to do for this, but at the end of the day there are bound to be a few gotchas that crop up along the way…so, I’m thinking I’ll keep my blog updated with progress, and describe any nasties we come across as we go. I’m also thinking of putting together a series of tutorials in the style of the “hands on labs” you get at Tech-Ed and the like, related to this. If I do this, then I’ll make sure I post them here too…

So far, we’re looking at the following types of customisation:

Custom Work Item Types
Process Guidance
Default work items for new team projects
Default check-in policies for new team projects
A new check-in policy
A couple of new reports
A custom Team Build step to label source control for each build

Plus we’re also going to build some integration components to manage synchronising updates to work items in TFS with our corporate standard change management tool, Borland StarTeam, and vice versa. We’re also going to look at doing similar things for TFS and MSPS (MS Project Server)

Running TFS successfully in a Virtual Machine

So after much wailing and gnashing of teeth, our TFS setup seems to be pretty stable now. We have a real server on the way for it, and we’re waiting till thats up and running before we go full on with migrating from VSS and Clearcase to TFS.

But for now we’re still using TFS from a Virtual Machine. Through much pain I think I’ve figured out the best way to set up the VM so that it can survive the worst that crappy hardware and dodgy server admins can throw at it…So far it’s survived two unscheduled reboots without needing to be rebuilt, so I’m pretty happy with it…

Here’s a brief rundown on how I’ve got it configured:

TFS is installed as a single server instance, in a Virtual Server 2005 VM. Our VM is using 1GB of RAM, and Virtual Server reserves up to 100% of one CPU (The host server is a 4-way Xeon box, so we have 8 logical CPUs in total).

I’ve got two Virtual Hard disk drives, set up to use a virtual SCSI controller, rather than as IDE drives (this seems to be the more stable way, and is faster). The data drive is set up as a fixed size drive as well (20GB), which again improves resilience and performance.

We’ve got SQL Server backups running for the TFS, Reporting Services and Sharepoint Services databases, with the files stored directly on a share on the Host machine, rather than having them saved to a folder on the VM itself.
The SQL backups run as follows: Full DB backups at 1am every Saturday; Differential backups at 1am every other day; Transaction log backups run every 4 hours, starting at 3am every day. I’ve scheduled these like this to avoid contention with a couple of built in jobs – when they ran in tadem with the other jobs, the backups appeared to finish successfully, but when I tried to restore from them, SQL Server would report that the database “was corrupt when the backup was made” for the databases where the TFS admin jobs were running – I’ve not seen this happen since I set the SQL backups to run at a different time to the TFS jobs.

Finally, I also have a backup clean-up job that runs at 2am every Sunday, to keep the number of backup files, and the space they take up, down to a minimum. I keep 4 weeks worth of backups online at any one time.
 

Mondayitis

I normally don’t mind Mondays – a fresh start to the week (unless I was unlucky enough to have been called out over the weekend!!), other people have yet to discover nasty problems they need help with, the TFS server is under minimal load as people are only slowly getting back into work, etc, etc.

But TODAY!!!! Damn!

I had a presentation scheduled at work. Every so often we have a lunchtime presentation (EDS call them Brown Bag presentations, apparently in the US they all bring their lunch to work in a brown paper bag!!) and today I presented an overview of Team Foundation Server, including how it fits in with our other tools at work.

This raised a bit of last minute interest with our Process Improvement people as they have heard we want to (er….have already started to) use TFS for .net projects, and they need to understand what it can do/why we want to use it instead of VSS, ClearCase or most importantly Borland Starteam. SO, I didn’t finish writing the powerpoint slides on friday (last-day-of-the-week-itis hit me BAD on Friday), and I wanted to set up a local TFS VM for running demos during the presentation (again, that became a friday afternoon casualty). I figured I had the weekend to do this in, but forgot about a BBQ for my daughter’s netball team (which wife also coached) on Friday night, and a birthday dinner for my mum on Sunday. Also, with the netball season finally over, we have our “family day” back again (saturday), so I didn’t get round to progressing this over the weekend at all.

Anyway, one thing led to another and I ended up working from 6am this morning doing ppt slides with one hand and installing TFS into a VM with the other (no, not literally – jeez!!!).

I finally got everything ready with 20 minutes to spare before I was due to head up to the presentation room to set up. I get there and the network for the TFS VM I had set up, decided to go mental. My laptop siezed up, and I had to reboot – somewhere along the way Virtual Server decided it was going to refuse to network properly.

So I was forced to do my demos on our production TFS box (we have a sandbox project on it that I was able to use)…using NetMeeting to link up with our boys and girls in Hamilton and Auckland, plus a stray Upper Huttian or 2, I shared my desktop and got through about half a dozen slides before someone told me I had the slidshow underneath something else on my desktop, so everyone who was remotely watching with NetMeeting missed the first part of the powerpoint!!

With this, and the network screwup making everything slow down, I ended up running over time and having to skip one of my demos, which made the whole thing seem a bit rushed. Finally, to top that off, I got stuck afterwards in a discussion (which was a bit one-sided) with one of our Process Improvement people about what she wants to see in a decent SCM tool, for another 10 minutes.

AND THEN, to make matters worse, I get back to my desk only to be called into a meeting where we all get told that the project (a BIG one – actually a multi-year programme of work, rather than just a project) that has been just around the corner for the past 12 months or so, will not be starting up in the beginning of next month - instead, it’s not likely to be ready to work on till probably the end of Q1 next year now, and theres no guarantee we’ll get to do the work either!!

Anyone else have a crappy monday? :/