Agile Storyboards and TFS2011 Preview

In an earlier post I talked about agile, and how we can manage stories and tasks by using a storyboard.  If everyone is keeping the board up to date, you can glance at the board and see the state of the project.  You can see who's working on what, what's done, and whats left to do.

But what if the project is being managed across more than one site?  And isn't maintaining a board, and what's in TFS a complete pain in the arse?

This is where a new feature of TFS2011 comes in.  A virtual storyboard.  In the web version, under 'WORK', click on 'board', and you get a list of all the stories and tasks in your project:

I can drag and drop my story in to the Active column...

That's brilliant.  Previously, we had to go into TFS, go in to the task and manually edit the task.  Now I just have to drag and drop it.  Easy!  I can check it in TFS - it's definitely updated my task...

As you can see, it hasn't set my Story to 'Active', but it's fairly easy to click the Story title and update it manually in the browser:

Love it!

Why I prefer Agile, and how we get stories and tasks in to TFS

• Agile vs Waterfall.
• Writing stories vs being spec driven. 
• Delivering on time, on budget vs moving deadlines and changing budget

I've worked in a number of environments. 

At one job in London, we had no project planning, it was pretty much a case of having a chat in the pub, coming up with some ideas, then giving a rough estimate on how long it would take, then coming back a few months later and asking if that's what they wanted.  It worked because we worked very closely with the business and had a good idea of what they wanted.

At Vignette, we had full on Waterfall drilled in to us.  Plan, plan, plan.  Spend yonks planning, get it all detailed, then spend a short time doing the implementation. The great thing with this is that developers can come and go, and as long as they following the spec, they can chop and change people.  The risk is reduced.  You can divide it all up and have people in different offices deliver different parts of the system independently.  Really?  

The danger with this is that technology and companies change so quickly that the requirements can change.  The director that signed the deal could have moved on, and then someone else comes in, has different ideas, wants to do some cost cutting, believes in different technology.  Whatever.  From signing the original deal, doing all the up front planning, and eventually delivering it, the needs will undoubtedly have changed.   How do companies deal with this?   They put in some form of change control management.  So if requirements change, they can renegotiate the deal.

This is the great thing with Agile. You don't plan everything up front to the Nth degree, you feel your way to the solution. You come up with high level stories.  You do some very high level estimating against story points.  From this high level estimate you can give your timescales. You break it up in to Iterations - where at the end of each iteration you promise a delivery.  Within each Iteration you have a series of timeboxes.  Each timebox is managed as a detailed project.  It's within the timebox that you break your story down into a number of small manageable tasks, and you give your high level estimate against the task.  You don't have to break a story in to tasks, but I find it helps me.

You need to ensure that your story is delivered within the timebox.  If you can't, your story is too big.  Likewise, your task should be do-able in a day.  If you can't, try to break it down.

Its pretty much common sense.  You concentrate on the things you need to do next.

So, if you're used to spec driven waterfall, how do you get your head around Agile.  Do you still have requirements?  Of course you do, these are your stories.  You write your stories like this...

As a <type of user> I want <some goal> so that <some reason>

This could be something like:

As a customer I want to purchase my car insurance online so that I can save time

Actually, as a story, that's way too big, we'd refer to that as an Epic.  We could break it down to smaller stories...

As a customer I want to supply my postcode so that your system can look up my address and I can save time

That's probably quite a reasonable story.  You could realistically implement your address look up within a 2 week timebox.

You'd then break your story down into a bunch of tasks that the individuals on the team need to do, and put an accurate estimate in against the task.
You put your stories on cards, put your tasks on cards and then have a board up on a wall with people names down the side and a few columns along the top:

• Unassigned
• In progress
• Awaiting code review
• Checked in, awaiting deploy
• In test
• Complete

Or a flavour of your own to suit your own team and project.   On the back of the task card you can write the tests required to satisfy the testing of the task.
How do we put these in to TFS?   It's really easy.   In your Team Explorer, right click on 'Work Items', select 'New Work Items' and then choose 'User Story'.  Add your Story...

Add New Story

Then associate your task, under the 'All Links' tab, click the new button, as shown:

Add New Task to Story

This'll pop up a new window, where you insert the Task name:

Insert the Task Title

As you can see, it's adding the task as a child of the story.  Once you've chosen the task name, it'll switch to the Task details...

Add Task details

I've got the name in there, and put the same in the details.  However, in the details, you should really put in the detail of whats actually required for the developer to complete the task.  Under 'Effort', this is where you need to enter the time estimate.   As a developer works through a task, they can update the tasks, and change the figures for the hours done (completed), and left to go (remaining).  This helps when calculating the burndown.

So, I've now entered a few tasks against the story:

Three Tasks added to Story

What you'll see above is that the Story is assigned to me, and has a state of New.  When I start a task, I should change the Task and Story state to 'Active'.   Then as I complete my task, I can set them to 'Complete'.  Once all my tasks are 'Complete', I can set my Story state to 'Complete'.

Finding your way around TFS with Visual Studio 2010

So, one of my best friends has been using TFS in his work place for 6 months now, and we've also been developing some software together.  We've been using Subversion (SVN), with Ankh SVN, integrated into Visual Studio.  When the opportunity came up to try TFS2011 (with tfspreview) I decided to migrate us over. We'd been running with it for a couple fo weeks, but it was obvious I needed to get my mate up to speed with TFS.  I've been using it for over 4 years and started with TFS2005.  I've been happily using TFS2010 for a while.  So I went through and scribbled down the basics of some of the common features of TFS and sent them over in an email.
Again, its a lot of info that is probably best shared.


First thing you need to know, TFS isn't just a source control repository, but that's all we've been using it as so far.  The example below is showing two separate MVC3 projects, but they're not the point of this post, so I won't talk about them here.

Solution Explorer:

Solution Explorer

You know what this is, its the Solution Explorer, the clue is in the name.   However, it's worth mentioning the little symbols next to each file:

- the padlock means the file is checked in to TFS.  Nobody else has it checked out.

- the little person icon means its in TFS, but someone else has the file checked out.

We can have different types of check out.  We can lock the file exclusively, which means nobody else can check it out.  Or, as we have it set up, we allow parallel checkouts.  When you come to check in, if you're the first, it's straight forward, its a check in.  If you're following a checkin, you'll have to merge the file.  It might do it automatically, or you might have to manually merge it, in the merge tool. 

Why does it sometimes make you merge it and why sometimes can it automatically do it itself?
Lets say I make a change at the bottom of the file and you make a change at the top.  It's easy for the system to merge this, it'll do it itself.  But, if the changes are on consecutive lines, or even on the same line, then it'll ask you to merge the conflict yourself. 

Some say it's good practice to 'get latest' before checking in.  I'm not so sure.  But if it ever asks you to merge a file, lets share desktop and resolve it between us.

How do I find out who's got a file checked out?
If someone has a file checked out, you'll see the little person icon next to the file.  I'll show you the source control explorer later.  All you need to do is navigate to the file in the Source Controller and it'll show you who has the file checked out.

How do I add a new file?
If it's a piece of code, go to the directory you want to add it to, right click...

Add a new file to TFS

...and add your chosen type.  I chose to add a class, and call it bollocks...

New File Added to TFS

A new + symbol, that means its just been added to the project, but not yet checked in to TFS.

But, I've got an image I want to add!!
That's fine, just add an existing item...

Add an existing file to TFS

And your new file is in the project:

Existing file added to TFS

Next up, Pending Changes:

Pending Changes

Anything that you've added, updated, deleted, moved, etc will end up in your pending changes window.  I've got mine to show up at the bottom of the screen:

Pending Changes

So, my project file (MvcExample.csproj) file has been ammended because I've added two new files.  Then you can see that it's showing my two newly added files.   newImage.png is also marked as locked - this is because you can't have a parallel checkout on an image - how on earth would you merge it?

I'm not going to check these in, I don't really want them in my solution.  Instead, I'm going to highlight all 4 files and undo...

Undo Pending Changes

Next up, Team Explorer:

Team Explorer

Team Explorer

If we had multiple projects, we'd see more than just 'EntraNet', but that's our project.  Within there we have three items.

• Work Items
• Builds
• Source Control

Work Items

We have a number of types of Work Item, and you can add one by right clicking and selecting New Workitem...

New Workitem

What are they all for? 

Bug
Ok, register a bug if somethings broken.  If you're getting an error, or its just not working, raise a bug.

Bug

Its fairly self explanatory.  But please do fill out the Repro Steps as though I'm an idiot.  I, or anyone, should be able to read the steps and reproduce the bug.  If I can't reproduce it, its not an bug.

Code Reviews, request and response
We use these extensively at work, but lets skip these 2, we're not using them.  Essentially, we can put in some check in rules, so that we can't check in without the changeset being reviewed and approved.

Feedback - Request and Response
I've never used these before.  These are new to TFS 2011.  Do we want to make use of this?  More details here:  http://blogs.msdn.com/b/visualstudioalm/archive/2011/09/20/feedback-on-working-software.aspx I think it probably makes sense.  When I think something has got to a state where it's usable, I can initiate a feedback request - and we do it via TFS, rather than email - so its all recorded.

Issue
Another new workitem type.  If there's something missing, or you don't like the way something works, raise it as an issue.  All comments get recorded in TFS.

Issue

They look fairly straight forward.

Shared Steps.
I have no idea what these are, lets ignore these.

User Story
A Story is a high level requirement. Something like:

As an Administrator, I want to be able to administer countries, so that I can keep my country list up to date

Task
Tasks hang off stories.  These are the physical actions that people need to take to complete the story.

Builds
Lets forget builds for now.  That for when we want to define a build, that builds our project, via a series of scripts, on the server (or another configured build server)

Source Control
This opens the source control explorer.

Here we can explorer the source, directly within TFS. We can navigate our way to a solution, and open directly from TFS:

Open a solution from Source Control Explorer

Double click the '.sln' file and it'll open the entire solution (in this case with 2 projects); A solution consists of one or more projects. 

You can get the history of of any item in source control, by right clicking and 'View History'

View History in Source Control Explorer

So, here I'm wanting to view the history of the whole of the solution.  It shows me all changesets in the history of the solutiuon.  You can check the history at Solution, Project Directory or Fiile level.  The history looks like this:

It's not showing the individual changes to files, its showing you each Changeset.  A changeset is the set of files grouped at a single checkin.  If you check in a single file on its own, you create a changeset with a siingle file, if you check in 100 files together, you've created a changeset with 100 files.

You can see the contents of a Changeset...

View Changeset

And you can see the specific changes in the file by drilling down even further...

Compare with Previous Version

Then that shows how it was, and how it is now...

View Differences