Estimation is probably the most valuable skill you need to cultivate as a developer
The difficulty level of a user story, expressed in points
Some people prefer to estimate in absolute time, expressed in hours or half-days, but in order to develop a good sense of relative time, for now we will estimate our user stories in points
The team capacity, expressed in points, for each sprint
A prioritised backlog of all the user stories that we estimate will be completed in the next sprint
Where the team reprioritises user stories and agrees the next sprint backlog
Where the team compares their estimate with the actual number of user stories completed
Not all issues raised in the project board contribute to the velocity estimate. Chores, bugs, refactors and spikes are all zero-point issues, even though they will (seriously) impact your sprint velocity.
To be added to issues
E1
- Short story, estimatedE2
- Story, estimatedE3
- Long story, estimatedE5
- Extra long story, estimatedA1
- Short story, actualA2
- Story, actualA3
- Long story, actualA5
- Extra long story, actualstory
chore
bug
refactor
spike
Label all issues correctly before addressing them
It always takes longer than you expect, even when you take into account Hofstadter’s Law.