Blog

Story Point Paradigm

Hello AstroGrism Development Team!

Harry Ferguson has allowed us (STScI Indigo ScrumTeam) the ability to try out any new workflows here we might want to fold back into Indigo. As per JDAT-410, we are having issues with accommodating for work done, captured by subtasks, during the sprint when the parent story has not been resolved. When the story rolls over to the next sprint, what do we do to the story point estimation? Do we overinflate the remaining work in the next sprint? Or do we "destroy" the work effort completed last sprint in favor of an accurate estimate next sprint? To capture work done in the subtasks, I've designed a new workflow paradigm for us to try this sprint: Subtask Story Point Decomposition.

The Subtask Story Point Decomposition

  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.
  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.
  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, 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.  
    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.

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.