Story points are a measure of the effort/complexity/doubt of a ticket.
Effort can be thought of as how much raw work there is. Looking at 1,000 product images and validating that they do contain the product they claim to is an example of high effort work.
Complexity is how tangled this problem is with other stuff. A movie depiction of defusing a bomb is a good example of something with lots of complexity but minimal effort. It’s just one wire to clip.. but it’s figuring out which wire.. that’s the complexity.
Doubt is how familiar we are with something. A non-reproducable bug would be an example of a high-doubt scenario. Someone’s first experience with adding a feature into a go binary would be another.
When we point stories, we try to pattern match the effort/complexity/doubt with other stories that we know about. This is called “calibration” and it allows us to estimate as a team. The examples below are just examples. Feel free to choose your own stories and your own point assignments for them. The story examples below are just my thought on what these point values should be. This is something that’s ultimately an internal concern of your team. As stories get big (8 points is pretty big), they should be broken down into smaller tasks.
Points are expected to be additive. Two 3-point tickets are approximately the same amount of work as a 1 point and a 5 point ticket combined.
Estimation is a group activity. More brains thinking about this is better. People will come up with things you didn’t think of about why something is harder/easier than you expect (especially if they’re cross-functional like FE/QA estimating BE tickets).
| Ticket | Points | Effort | Complexity | Doubt |
|---|---|---|---|---|
| fix the build that stopped respecting the @skip annotation | 1 | Low | Low | Low |
| fix broken otel implementation in a small microservice | 1 | Low | Low | Low |
| Add ‘age’ to the API endpoint | 2 | Low | Low | Low |
| speed up worst performing unit tests | 2 | Medium | Low | Low |
| Fix 33 failing unit tests 3 | 3 | High | Medium | Low |
| Implement fraud checks for 2 security-critical user operations | 5 | Low | Medium | Medium |
| Setup new relic for service and adjust it for scale | 5 | Low | Medium | High |
| Sometimes a service becomes unresponsive. Fix that. | 8 | Medium | High | High |
Design docs are a special case, because it changes depending on what it is you’re doing. Here are some approximate point values that I’d put on different things I’ve seen or written.
| Ticket | Points |
|---|---|
| multi-team initiative to solve systemic quality issues | 13 |
| deduplication effort for component jointly owned by 2 teams | 8 (to account for coordination) |
| brand new JWT-based auth service | 5 |
| Guidelines for performance/UX/kill switch for new vendor tool | 3 |