Story Pointing - Fibonacci Time Points

How we point

There are many ways to estimate. Currently, we provide a number to represent a rough time-based approximation of how much total work it will take to complete the story (including considerations from the Definition Of Done ).

We roughly equate points to the following time estimates:

1 - one hour
2 - two hour
3 - four hours
5 - one day
8 - two days
13 - one week      - should be used for epic or initiative planning
21 - one sprint    - should only be used for epic or initiative planning
34 - two sprints   - should only be used for epic or initiative planning  
55 - four sprints  - should only be used for epic or initiative planning
89 - eight sprints - should only be used for epic or initiative planning

For new teams, a reference frame for story point meaning avoids confusion. Later, teams can evolve how they point.
Using a fibanoicci sequence avoids estimates getting too fine grained.

We use Pointing Poker to collect points from the team. Once a story is pointed, it is labeled as Ready and optionally assigned to the person person who will take up the work.

Why we point

Alignment - Pointing is a "shorthand check" to make sure everyone has a similar conception of the work required. If the team is asked to "build gobbledygook" and one person estimates 21 but another estimates 3, we are not on the same page. We need to figure out what the misconception is.
Incrementalism and Prioritization - If something is unexpectedly large, we can look for ways to break up the work or prioritize something else.
Communication - If the work starts and it's discovered the work is going to take a lot more time, devs should communicate this and make sure everyone is good with continued investment.
Coordination - Often, work might span across multiple teams. For example, a Frontend Podmight depend on Backend Pod A which depends on another Backend Pod B. To avoid wasted time & effort, coordinating the handoff of work requires as much certainty as possible. By having predictable results, teams can better coordinate their work to maximize their effort. For example, the Frontend Pod above should know that a feature from Backend Pod A will actually be completed within a 2-week horizon.

Why we DONT point

The following are NOT the goals of story point estimation:

Measuring developer performance. 👎
Holding people accountable to individual estimates. 👎