Story Points

Estimating the amount of work in a project needn't be difficult. Story Point estimating is quick and can be painless.

We use relational (or affinity) estimating to compare one requirement (story) against another.  Is it larger, smaller or roughly the same size?

So print each story on to a card and then go through one by one comparing the story against those already compared.  

Once you've been through and done the comparison you should have stories in piles.

Apply the Fibonacci sequence to piles.  The smallest getting a 1, the next set getting a 2 and so on.

We tend to then go through each pile and confirm that we are happy that the stories in each pile fit the story point size assigned.

Remember...

• A story point is not a unit of time

• A story point can only correlate against a unit of time when the story point numbers are very low

• The larger the number, the less correlation between time and story points.

• We deliberately use the Fibonacci sequence to show that the bigger the story, the bigger distance between numbers in the sequence, and the less accurate an estimate on a large story will be 

Eg. So, a story with 1 or 2 points should be fairly accurately estimated.  But the larger the number the less accurate our estimating is.

Let’s say we have calculated our velocity 2 story points per day.  It doesn’t mean we’ll deliver a 13 point story in 6.5 days, but we can probably accurately estimate that we can deliver 13 one point stories in 6.5day.

So, if we’ve got an 8 point story, the assumption is that’ll take 4 days, but the reality is that’s not accurate enough.  It could take 3 to 6 days..?

And, if we’ve got an 8 point story, we’re not going to see any burn down on our chart for a while.

So if everyone is working on large stories, our estimating is inaccurate, our project is at risk from the start, and we’re unlikely to see regular burn down in our timebox.

We can probably live with 5 point stories, as we can probably live without burn down for 2 to 3 days.  Hence, I’d say we should break down stories that are 8 points or more.

A few ways to think about it, and it’s always with distance, as it’s easier to visualise.

The accuracy of a story estimate is a bit like throwing a dart.  If it’s a small number, it’s like having the target a few feet away.  You’re going to hit the target and are more than likely to hit it exactly where you aim at.   But a larger number is like getting further away.  The further away you get, your chances of hitting the target decrease.  Get too far away and you’re much less likely to hit the target at all.

Or think about travelling distances.  If you live in the south of England and someone asked you about travelling from Woking to Reading, you might have a good idea about how long it would take. But what if it were Darlington to Durham, York to Leeds,  Manchester to Northwich?

Something you’ve done many times, you can have a good idea of.  But if you haven’t, you have to compare it against something similar.  All these journeys are about 25 miles, do it’d probably be safe to assume that they’d all take the same amount of time.  But I know that my journey from Darlington to Durham is going to be much quicker than your journey from Woking to Reading.

It's quite comparable, but it's still quite a distance.  More factors can take effect and increase journey times.

Change that to a much smaller distance like a walk to your local pub.  If my pub and your pub are both 200yards away, the estimates will be the same.  If there is a difference it's more likely to be seconds, rather than minutes.

Change that to a longer journey, like London to Edinburgh.  Even if you've done it a dozen time before you're still not going to be able to give an accurate figure.

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