How We Use Asana

Story points are a unit of measure for expressing an estimate of the overall effort required for a task.

We use them instead of hours because—like many other software teams before us—we've found the relative values of story points more useful than absolute values like estimated hours.

Relative, Not Absolute

With story points, we're thinking in terms of relative quantities. We're comparing the effort of one task to another.

So instead of saying, "Task A will take 8 hours and Task B will take 3 hours," we're saying, "Task A is about two or three times as much effort as Task B."

☝️ In this example:

• If Task B is a 2
• Then Task A would be a 5

	Story Point(s)	Effort	Complexity	Risk / Uncertainty
🟢	1	Virtually none	Very little	None
🟢	2	Minimum	Little	None
🟢	3	Mild	Low	Low
🟡	5	Moderate	Medium	Low
🟠	8	Considerable	Moderate	Moderate
🔴	13	Maximum	High	Severe

Remember: Story points are a measure of effort, complexity and risk. They are not a measure of time.

Rules of Thumb

It can be hard to shake the habit of estimating in terms hours, but it's important to remember that story points are not a measure of time.

That said, it can be helpful to think of them—in an aggregate sense—in terms of rough time-based rules of thumb.

For example:

• A "productive workday" is often the completion of roughly ~5 story points.
• A "productive workweek" is often the completion of roughly ~20 story points.

This can help with expectations, planning, and understanding the scope of a task.

Examples

1 Story Point

• Updating copy within code; no associated HTML or CSS changes
• Fixing a typo in documentation or updating a screenshot

2 Story Points

• Simple CSS changes on a stylesheet that only affects one page
• Syntax corrections to existing code
• Very simple bug fix that does not change the signature of any existing function or class
• Dev discovery

3 Story Points

• Simple bug fix that’s distinct to a single part of the code base
• HTML/CSS changes that are simple in nature, but affect adjacent nodes or require responsiveness consideration

5 Story Points

• More complex bug fix that requires some new code or refactoring to resolve, and the origin of the bug will take some work; the bug is easily replicable
• A new feature that is relatively simple in nature and doesn’t require significant modification to existing code

8 Story Points

• This is the maximum allowable story points for a single task.
• Anything above an eight likely needs to be broken down into a bucket of smaller tasks.
• We should try to avoid 8’s as much as possible and break down into smaller tasks to reduce risk, complexity.
• Examples:
  • Bugs which can be replicated, but will require considerable work to determine the origin of, or the origin is known and will require extensive work and refactoring to address
  • Features which will require considerable learning in order to build, is introducing a fundamentally new module to the codebase, or have a moderate level of unknowns

13 Story Points

• ⚠️ An estimate of 13 means we must break it into smaller tasks, e.g. a "bucket" with multiple tasks.
• A bug that is not reliably replicable or would require a fundamental change to the system to address
• An open-ended feature that has virtually no real scope or massive unknowns and should really be broken down