Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. As in "vanilla" Scrum Theory, once the Product Owners get together and create the prioritized list of stories for the development team to work on, the development team will get together to measure the complexity of each story. These stories will be valued by the Fibonacci Sequence.
    1. Image RemovedImage Added
  2. As we do on Indigo, once stories are assigned to developers, each developer will take each of their stories and break it down into subtasks, which symbolize the individual pieces needed to accomplish the broader story, as best they understand the problem.
    1. Image RemovedImage Added
  3. This is where our procedure will diverge from Indigo's procedure. Once the subtasks are defined, the developer will assign story points to these subtasks, considering the first based on the relative size/complexity of each subtask relative to each other. Consider the upper story estimate to be the "total bank" of story points available. So a story originally measuring 8 points can be decomposed into two 4-point stories, four 2-point stories, one 6-point and one 2-point story, etc. The sum of the subtasks' story points MUST NOT exceed the original estimate of the story. These subtasks do not need to follow the Fibonacci Sequence.
    1. Image Added 
    2. Ideally if all work is understood, and the subtasks' story points should add up to the original estimate of the story, then the original story's story point bank should be emptied (dropped to zero).
    3. If subtasks are missing due to unknown variables, the developer may leave some points in the original story's story point bank for later decomposition.
      1. Image Added

As subtasks are completed, their story points will be completed and counted towards the development team's burndown. This will accurately capture the development effort completed, as well as distinguish any remaining work that has not been completed, for each story.