| Story Points | Equivalent T-shirt size | Effort | Complexity | Risks | Unknowns | Description |
|---|---|---|---|---|---|---|
| 0.5 ~ 1 | X-Small | Very Low | Very Low | Very Low | Very Low | |
| 2 ~ 3 | Small | Low | Low | Low | Low | ⭐ Smaller user stories. Can be done by 1 person even a junior. |
| 5 ~ 8 | Medium | Medium | Medium | Medium | Low | 🌟 Most common and normal sized user stories. Can be usually done by 1 person. |
| 13 ~ 21 | Large | High | High | Medium - High | Low - Medium | |
| 40 ~ up | X-Large | Very High | Very High | Very High | High | 🚫 Elaborate and/or split. Avoid these kinds of user stories. Manage the risks and unknowns. |
- Effort
- How big is the task?
Does it require a lot of repetitive activities?
Does the solution involve a lot of layers and domains? - Complexity
- Does the solution require specialist knowledge?
Does it need to be specifically done by a senior developer?
If a less junior member of the team commit to it, is there a high possibility of failure? - Risks
- Will the solution involve massive code changes and refactoring and will inherently break a lot of things?
Does the team have an alternative or a workaround if the risks become unmanageable?
Will the solution incur technical debt? - Unknowns
- Does the user story have a lot of unknowns that the team is willing to extract and elaborate during the actual sprint?
- Be razor-sharp clear about what needs to be done to complete a particular user story. The whole team needs to understand the effort and complexity. Don't keep the knowledge to a single person. Knowledge silos will slow down the team.
- Highlight all risks during sprint planning.
- Remove all unknowns as much as possible. User stories should be elaborated continuously until it gets to its "ready" state.
- Be very critical about the scope of the user story. Be aware of scope-creep especially when building towards an MVP.
- Split user stories if you can especially if it can be delivered in parallel and without too much dependency.
- Identify the most common user story that is straightforward and can be easily identified as a "normal-sized" user story.
- Try to always estimate stories in the 2~8 range. A single person should be able to complete a user story of this size without too much help.
- If a user story has a lot of unknowns and risks, i.e. vague requirements, no design, suspect architecture, or incomplete DoR, the user story can still be pulled into the sprint but the team needs to accept and understand the risks.
- The team needs to be aware that since it's taking a very risky and very complex user story, everyone needs to be ready to swarm in and help.
- Non-build activities such as UX/UI design, technical design, architecture, analysis, investigations, research should be time-boxed to a certain number of hours or few days. The whole point is to validate and iterate the output of these activities so if say a design takes two weeks without any feedback from any person in the team, it will then create a knowledge silo as the team is unaware of what's going within those two weeks so then any future feedback and iteration will now take a longer cycle.