We use Story Points to estimate the complexity of our work. This is rooted in the agile development methods - a popular method for structuring work in the technology industry.
Our Story Points use a Fibonacci sequence for a couple reasons:
| Complexity | Meaning | Needs refinement |
|---|---|---|
| 1 | A trivial change that has zero chance of breaking anything. A copy change, adding comments to a file, changing minor CSS. In the worst case, should never take longer than a 1/2 day. | ❌ |
| 2 | A small-to-medium change that is mostly known, but requires a lil' investigation (maybe you don't know which file to make the change in). In the worse case, should never take longer than a 1 day. | ❌ |
| 3 | A change that is straight forward, but likely touches 5+ files, and may need to interface lightly with parts of the codebase you aren't familiar with. In the worst cases, should never take longer than 2 days. | ❌ |
| 5 | The "largest" estimate that doesn't eventually require further breaking down. The work has limited scope but requires decision making, planning, building, testing and more. In the worst cases, should never take longer than 3.5 days. | ❌ |
| 8 | Used to represent that a task is probably just a 1 - 5 pointer, but has substantial unknowns, and needs investigation and additional planning. Once done, it should be broken out into lower level cards before coding begins. | ✔️ |
| 13 | Used to represent that a task is likely more than one or two lower level tickets, has substantial unknowns, and needs investigation and additional planning (and likely approval from your peers). Once done, it should be broken out into lower level cards before coding begins. | ✔️ |
| 21 | Used to represent that a large feature that is very likely a handful of tickets, is almost entirely unknown, and needs investigation and additional planning (and approval from your peers). Once done, it should be broken out into lower level cards before coding begins. | ✔️ |