Email iconarrow-down-circleGroup 8Path 3arrow-rightGroup 4Combined Shapearrow-rightGroup 4Combined ShapeUntitled 2Untitled 2Path 3ozFill 166crosscupcake-icondribbble iconGroupPage 1GitHamburgerPage 1Page 1LinkedInOval 1Page 1Email iconphone iconPodcast ctaPodcast ctaPodcastpushpinblog icon copy 2 + Bitmap Copy 2Fill 1medal copy 3Group 7twitter icontwitter iconPage 1


Dig around Agile blogs and discussions and you’ll find a lot of debate focussing on what constitutes ‘done’. Done being one’s definition of complete for a user story. For me, knowing that we handle a user story from cradle (requirements gathering) to grave (deployment), with all aspects in-between, this is not such a complicated issue because ‘done’ simply means deployed to production at which point the story can be closed with confidence that it’s passed testing (automated and manual) and client QA.

What’s not so often discussed is the definition of when a user story is ‘ready to be done’. By that I mean, at what point in the lifecycle of a user story is it actually ready to be pulled into a sprint and worked on? With the help of Natalie’s snazzy design work I’m going to try to explain how we tackle this crucial part of the user story evolution.

Why it’s important to have a definition of ‘ready to be done’

I was inspired to write this article mainly because of a post written by prolific Agile blogger Vin D’Amico in which he describes the need to have a formal definition of ‘ready’ for a user story. The reason this is so important is because a user story is not an exact specification, it’s simply ‘an invitation to a conversation’. But that conversation may not have happened and therefore trying to pull it onto the sprintboard and tackle it before it’s ready is going to result in pain and frustration (you won’t get past day one before every story is ‘blocked’ and everyone is pulling their hair out).

Believe me, from experience this is not what you want and we’ve had some painfully unproductive and even abandoned sprints due to this happening in the past. It’s also rather humiliating for anyone involved in the sprint planning and user story writing to be told by your production team the equivalent of what Harrison Ford told George Lucas about his script writing skills:

George, you can type this shit, but you sure as hell can’t say it.

A user story needs to be nurtured

Think of it a bit like raising a child; as such, before it can leave home, your user story has some growing up to do and it’s your responsibility to make sure it doesn’t leave as a delinquent that no-one (AKA developers, designers and so on) can understand.

If you can visualise a funnel, new stories (or ideas) are poured in the top where they exist as loose, rough diamonds, gathered during requirements activities and workshops (whatever your flavour). Some stories might be epics requiring them to be broken down, some might not even be valid but they always contain enough information (even if it’s only a few words) to kick-off a further conversation. The point is that as a story gets refined it travels through the funnel until it’s ready to exit out the bottom, finally leaving home and free from the meddling of it’s parents. The exit at the bottom of the funnel is the point the user story is ‘ready to be done’ and therefore your refinement process (everything that happens in the funnel when nurturing your story) needs to ensure it’s ready to enter the world alone and prepared.

How will you know if a user story is ‘ready to be done’

Here’s a simple checklist to help you decide if a user story is ready to fly the nest and get into the grubby hands of one of your developers. If the answer is no to any of these questions, it’s likely the user story is not ready for your sprint:

  • Is there an acceptance criteria defined? If there isn’t, how will anyone know what ‘done’ looks like?
  • Do you have the required resource to complete the story? If you don’t, it’s already blocked and you’ll never be able to complete it.
  • Can your team relatively size the story? We use planning poker to relatively size stories against others in the backlog. Being unable to come to a consensus on size is a sure fire sign the story needs further refinement.
  • Does the team understand the user story? Being unable to come to a common understanding of the story will result in the wrong thing being built.
  • Does the client/product owner have the same understanding of the user story as your team? This is VERY important: if they don’t then it’s likely the story will be rejected at the client QA stage which is very frustrating because it takes such a lot of effort to get to that point. Tip: we overcome this by asking the client/product owner to be the orator at the planning poker session whereby they read out the user story and any acceptance criteria or further notes on the card and field questions relating to the story from the team.

Suffice to say, it’s not as simple as you might think and it takes a lot of effort to ensure there is a common understanding of what the story means to the team (our designers, developers and project managers) and the client/product owner. We’ve spent the last 6 months refining our user story funnel and feel it’s working well (although of course it is always subject to refinement).

Because we have such a wonderful designer in Natalie it wouldn’t be worth writing this article without having a nice infographic to go with it. This infographic is used internally to help us remember the flow and track our time and effort into Harvest (our time tracking software) appropriately.