Brainstorming “Done”

Being a new Scrum team, one of the things we’ve had difficulty with is actually completing the stories we set out to do in our Sprints. A lot of our tasks were pretty big, they didn’t move very quickly across the taskboard, we were  forgetting things like documentation, and the team wasn’t owning the estimates.

We decided to try something suggested to us by another Scrum team that we’d been talking to, who had been messing with Scrum for a year or so (they work for a different company nearby, we’ve recently started up a conversation and it’s great to get input from outside).

The idea was to brainstorm what it means to be “done”. We started with around ten or twelve criteria like coded, tested, and documentation completed. But when we brainstormed and broke it down further, we ended up with nearly thirty things identified. They’re pretty generic – I’ll list them at the end of this post.

The next step was to go through the list for every story that we took on in Sprint planning. Not every single thing on the list applied to every story, although most of them apply in most cases. For each item on the list, we created a task. This meant that task creation was no longer something that was owned by any one team member, and almost all of the tasks were a lot smaller – for example, we had to call out separately a task to review code, to review documentation, and to review acceptance tests, which we hadn’t done before. In this sprint, we’re tracking progress at a much more granular level, which means it’s far easier to see where the real hold ups happen, and harder to forget things.

This exercise isn’t completed yet though. The next step is to review the critieria at the end of this Sprint, identify the gaps, and fill them in. For example, I don’t think that “documentation written” is specific enough. If our documentation contains screenshots, a flow chart and a technical overview, let’s call that out. It sounds like over-planning, but it’s not – it really helps the team to see clearly what the tasks are and start to share them out more – which I think is one of the biggest challenges of being Agile.

The other thing we need to do is to write a sentence for each criteria to really clarify what it means to have met it. Watch this space for further updates on how this goes!


  • Story written
  • AB tests identified
  • UI designed
  • HTML written
  • Code written
  • Code reviewed
  • Unit tests written
  • Unit tests passed
  • Documentation written
  • Documentation reviewed
  • Acceptance criteria defined with stakeholders
  • Acceptance criteria reviewed and approved
  • Acceptance tests written
  • Acceptance tests published
  • Functional tests written
  • Manual tests carried out
  • Tested accessibility
  • Acceptance test done
  • Automation testing scope defined
  • Automated tests written
  • Automated tests run
  • Bug fixing
  • Regression done after bugfixing
  • Regression testing defined
  • Pseudo localised
  • Pseudo loc testing completed
  • Deployed to lab
  • Ready to present to stakeholders