Mark Needham

I’ve worked on a few different agile projects and one of the things that hasn’t been completely consistent is when we consider a story to be ‘done’.

There seem to a few different approaches, each of which has its benefits and drawbacks.

Why do we care?

We care about ‘done’ for tracking the points we have achieved in an iteration and for knowing when we have added the value the story provides. For this post I’m interested in ‘done’ in terms of when we count the story towards our points total.

Business proxy signoff

With this approach we count a story as done when it has been signed of by a business proxy, typically a client business analyst or maybe a combination of a BA/QA.

The benefit of this approach is that we have normally have better access to a BA meaning that we don’t end up having stories piled up waiting to be signed off as being done.

I have seen 2 mini approaches, both of which require a story walk through with the BA/QA:

• Acceptance tests pass => Done
• Acceptance tests pass + exploratory testing satisfactory => Done

With the first approach any bugs beyond the acceptance criteria will be tracked as bugs whereas with the latter the story will be moved back and just considered incomplete.

The disadvantage of either of these approaches is that we are counting something as done before it’s actually been signed off by the business, which means that we might have a false sense of the value we’re delivering. If the business proxies are communicating regularly with the business though I don’t think it’s necessarily a problem.

Business signoff

With this approach we only count a story as done when it has been signed off by our business stakeholder.

The benefit is that when a story is classified as done we have actually delivered something that is acceptable to the business.

On the other hand, when using this approach it’s fairly important to have access to the business stakeholder on a regular basis if the velocity of the team is to be measured accurately. When we don’t have this access we can end up with a backlog of stories waiting for sign off, all the while lengthening the time from when it was last worked on to when it is eventually considered complete.

In production

This is an approach which I haven’t seen used on a project but which I read across in a post written by David Laribee.

I can see how this makes sense as we haven’t actually delivered any value to our customer until the software is actually being used.

I think the difficulty of using this approach would be if we aren’t releasing code into production regularly – we wouldn’t get feedback on how we’re progressing and therefore would have more difficulty noticing when things in our process aren’t working as well as we’d hope.

In Summary

I think the further down the process we consider a story as done the more accurately our points total represents the value added to the customer.

Although we can get quicker ‘points feedback’ by classifying done earlier in our process, the accuracy of what that points total actually means is perhaps lowered.

I’m not sure which approach is the best one because each has its benefits and drawbacks. It will be interesting to see whether there are any further variations on what is considered ‘done’ on future projects I work on.

I am aware that I may be asking completely the wrong question and what we should be asking is ‘Does it matter when it’s done other than for reasons of tracking velocity?’