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'.