Skip to end of metadata
Go to start of metadata


  • Story - a short statement describing something we want the system to do, together with a short description if necessary. A story should be testable, and estimable up to 2 weeks. A story is not considered complete until it includes adequate unit & integration testing and documentation.
  • Task - A small unit of work that can be estimated up to 2 days. If code based it should include unit tests. A task is a sub-unit of a story.
  • Iteration - a period of activity at the end of which there is a compilable, demonstrable and testable system. These are not release cycles - a release cycle will likely include several iterations.
  • Velocity - the ratio between the real-life actual time taken to complete a task, and amount of time a task has been estimated to take.

Process summary

  • Short iterations. Short iterations provide greater flexibility and are more manageable. Because we have 12 weeks available until schedules T2 release (~ end June) we will work with 3x4week iterations.
  • At the start of each iteration we will have a group planning meeting. During this meeting we discuss the planned work, user requirements / use cases, and any additional work such as maintenance and bug fixing. During this discussion we will note down stories as they become apparent. When we feel we have covered all areas, the stories are estimated (based upon an ideal working day) and prioritised. A story that is not clear enough to be estimated, or whose estimate exceeds 2 weeks, is broken down into smaller stories.
  • By ordering by priority and based upon their estimate we can schedule stories into the following iteration. The estimate is factored by our tracked velocity, which for the first iteration we will assume to be 50%.
  • Stories that are assigned to the first iteration are distributed across the teams - assigning them as best as possible to the specialty of each team.
  • Each team splits the stories into smaller tasks (unless the story is already very small). Each task is itself estimated in terms of hours, with an upper limit of 16 hrs (i.e. 2 days). Once again these estimates are in terms of ideal days. Once happy with this split the overall estimate for that story is re-evaluated. These new estimates, which we would hope are more accurate, may allow new stories to be pulled into the iteration, or stories removed.
  • Each team now gets on with the work of implementing each task, according to their priority and inter-dependencies. This requires a bit of common sense and cross-team communication. Actual time taken is recorded for each task - this is the continuous time from start to finish, i.e. don't stop the clock whenever you have to go to a meeting. Note - this is not for the purposes of monitoring performance but is to allow us better determine our overall velocity and more accurately adjust our estimates in future iterations.
  • As we progress through the iteration we will review our progress and decide whether we can pull new stories in, or need to defer some stories until the next iteration.

Discovered stories / tasks

  • Its highly likely that as we progress through an iteration new stories will be raised or discovered. Because we are using short iterations, in the majority of cases these stories can simply be put to one side for the following iteration. Where a new story becomes critical to completing a story planned for this iteration, then it replaces the existing story which is moved to the next iteration. Depending upon its estimate it may mean that lower priority also get knocked off the bottom into the next iteration.
  • Also likely are discovered tasks. These are going to be shorter than discovered stories and are simply added to the current story and iteration.

Carrying over stories / tasks

  • It'll be a miracle if our estimates are spot on and we finish an iteration with all stories complete bang on time. By carrying out our stories according to our priorities, then for that iteration the key stories should be in place. Since we are regularly reviewing our progress there should be little overlap, and we just use a bit of common sense - either extend the iteration to allow for the overdue stories or knock these stories into the next iteration. 
  • None