Skip to content
This repository has been archived by the owner on Mar 27, 2023. It is now read-only.

Issue Sizing

Jump to bottom
Eudes Petonnet-Vincent edited this page Jul 3, 2018 · 1 revision

Goals

  1. Calculate and track the average velocity for each milestone
  2. Incorporate the average velocity into short-term planning (e.g. the next milestone) and long term planning (large features or major version releases, etc)

Sizing issues

Sizing issues is the first step to calculating the velocity of the Clarity project. We are trying to keep to the practice of non time based estimates for level of effort to complete an issue. By keeping the issue sizing process light we strive for two things: an average velocity and a long term planning and estimation formula based on the current average velocity.

Because we want to keep this process light final issue size estimates are left to the engineer or designer doing the work. We rely on our teammates to keep us realistic so that the average velocity reflects what the team can accomplish on a per milestone basis.

Sizing is based on the Fibonacci sequence and is used to indicate larger and larger chunks of work to reach a goal (from resolving an issue to releasing a large new feature or Clarity 1.0.0). Sizes are based on an understanding of the work needed to resolve the issue.

Scale and Description

  • 1pt - (Small issue) is an easy issue to complete. It involves straight forward and clearly defined changes.
  • 2pt - (Small issue) is simple but not easy. It is has clearly defined and well understood changes but is more in depth.
  • 3pt - (Medium issue) is straight forward with more involved changes to architecture or, has new 'things' that need to be built and tested to resolve the issue.
  • 5pt - (Medium issue) is more ambiguous that might or might not take some researching and prototyping to resolve the issue.
  • 8pt - (Large issue) is not straight forward. Has several unknowns that need to be researched/prototyped and will likely go through several rounds of design review before implementing the changes.
  • 13pt - (Large issue) is complex and will very likely be an ongoing development task. Should probably be broken up into a smaller mvp issue and one or two enhancement issues.
  • 21pt - (Small epic) A combination of 1-2 issues (sm/md/lg) that need to be grouped and delivered together.
  • 34pt - (Medium epic) A combination of 2-5 issues (sm/md/lg) that need to be grouped and delivered together.
  • 55pt - (Large epic) A combination of 5+ issues (sm/md/lg) that need to be grouped and delivered together.
  • 89pt Used for long term planning and applied to large chunks of work needed to reach a pre-defined goal.
  • 144pt Used for long term planning and applied to large chunks of work needed to reach a pre-defined goal.
  • 233pt Used for long term planning and applied to large chunks of work needed to reach a pre-defined goal.
  • 377pt Used for long term planning and applied to large chunks of work needed to reach a pre-defined goal.

Long-term Planning Example

Imagine that our velocity is ~16 pt / milestone and we have something big to accomplish by October 1st. This gives us 20 milestones (sprints) to work on the issues. And for planning we group the smaller issues into larger epics that can be (roughly) given a size. Once we have an epic size estimation and a fixed date we can connect the dots. Thats step one. This info can be saved and adjusted as time moves forward giving the team an indication of its progress towards the October 1st goal.

fullsizerender

Clone this wiki locally