This document describes what different story points mean in practice. By design, story points are not supposed to be connected to units of time (hours, days or weeks). They are meant to be relative units which give a rough understanding of the amount of work required to complete a story. Story points between different teams, departments and companies should never be compared.
Team A delivering 100 story points in a sprint might actually be much more than Team B delivering 200 story points because the teams don’t share a standardised definition what 1 story point means. By no means is this an attempt to create such a standardisation, but to give us a guideline what to follow when estimating stories.
For all stories, the pull request still needs to be reviewed, automated tests have to pass and a new version get deployed to be able to mark it as completed. This is an overhead that should be included in all estimates. Sometimes this overhead takes much more time than completing the actual work.
This is a very simple task. Something which requires maybe updating one or a few lines of code. Fixing typos in the copytext. Changing the value of a configuration variable. No major changes in the logic, nothing should break. No external dependencies. Any team member can do it based on the information that’s written on the ticket. Existing automated tests or very simple manual smoke tests verify this, and they don’t need to be updated.
This is still a simple task but roughly twice the effort of the 1-point story. You may need to update 3rd party dependencies, update the code to match the new API and verify it didn’t break anything. Refactor a method or two without changing the output. You may need to write a new test. The external dependencies outside of the team are simple, i.e., whitelisting a new Docker image version or submitting a ticket to another team, but you already know what you are doing, or it’s clearly documented.
Now we enter the slightly unknown territory where completing a ticket takes a significant amount of time. It is not simple, not quite complex either. This story may contain more external dependencies. You may have to update a major version of a 3rd party library, which has some breaking changes in the API. You may have to talk to another team, but you don’t quite know the details and there’s no documentation to follow. There are unanswered questions, but the expectation is that the answers can be found without major effort, i.e., during one quick call or on Slack. Most stories should be 1 to 3 points but no more than that.
Similar to the 3-point story, but this one has significantly larger amount of work. There are more unknowns. There are major breaking changes in one or more 3rd party libraries, which require rewriting the logic in several components. You have to refactor existing tests and write new ones. If you are dependent on other teams, it may require more than one meeting where several people are included.
This goes to the hard limit of what is reasonable to expect to complete in one sprint. There are major breaking changes that require a lot of refactoring, rewriting business logic and tests. This is a story where you build a new medium-size API integration or completely refactor an existing one. It’s unknown territory and you don’t quite know what is really expected until you start working. You should probably split it to smaller pieces, if possible. We’re talking about replacing request with axios or updating an outdated large module to the latest version.
There’s no reason to have stories with this much complexity. They will definitely take longer than 1 sprint to complete. Maybe longer than 2 sprints. There’s simply too many question marks and unknowns. It’s likely that the estimate is too optimistic. Split them up in smaller chunks (subtasks) or update them to be epics. We’re talking about something like “Integrate to Big Corporation API” or “Implement new branding”.