Each task requires an estimated point value based on time, complexity, and unknowns. Ensuring tickets are broken down into sensible, actionable chunks can reduce unknowns and allow the team to point a ticket based on the task’s time and complexity. A good scale to use for point values is the fibonacci sequence (1, 2, 3, 5, 8, 13) because it reflects that uncertainty on how to execute a task increases with task size.
A team should point each ticket as if any member were to take it on. This increases team flexibility and improves the quality of task estimation. Team members should therefore estimate each task as a group, and converge on a point value on which every member agrees. One method is planning poker, in which each team member reveals their individual point estimation of a task at the same time before the team collectively decides on the appropriate point value.
In practice, estimating point value based on time alone without considering the complexity or associated unknowns of a task can lead to poor estimation. However, a variable like complexity does not have inherent upper and lower bounds, whereas the maximum amount of time available can easily be determined.
It can be helpful to consider brackets of time when pointing to set some common ground among team members amidst discussion of a task's complexity and unknowns. In the example table below, a low complexity 3-point task might take closer to 4 hours for the average team member to complete, while a high complexity 3-point task might take closer to 8 hours.
| Points | Time range |
|---|---|
| 1 | A few minutes |
| 2 | A few hours |
| 3 | Half a day |
| 5 | 1 day |
| 8 | 2 - 3 days |
| 13 | 1 week |
Example of how a team maps ranges of time to point value to facilitate task estimation
The table above (and best practices in pointing in general) is by no means prescriptive. A team should determine in practice the guidelines that work for their needs.
It does not matter if two teams use different pointing scales or rules of thumb, as long as they are consistent within their own team. For example, a team might decide to break any tasks assigned a point value of 13 into multiple, smaller tickets because a 13 suggests the task is too vague or has too many unknowns.
Velocity tracking uses a team's average historical output to inform how much work (measured in total number of points) to commit to in the next sprint. Velocity tracking can also help a team reflect during retrospective on how much work was accomplished by comparing their estimated sprint velocity to their actual sprint velocity, often visualized with a burn-down chart.
Sprint-velocity describes the rate at which work is completed over the duration of a sprint. In other words, sprint-velocity reflects the number of points completed by the average team member in one hour (or points per person-hour).
When using sprint-velocity to plan a sprint, a team typically wants to know its average velocity across fairly recent sprints to get an overall sense of a comfortable pace. We will refer to this later as the average-sprint-velocity.
- Determine the number of total available hours for the next 2-week sprint. If a team has 4 members, and each can contribute 40 hrs per week, there is a total of 320 person-hours.
total person-hours = The sum of the hours each team member can contribute to the sprint
- If a team is planning their first sprint and has never tracked velocity before, they should choose a "seed" sprint-velocity value, such as 0.5 points per person-hour, to get started.
seed-sprint-velocity = number of points per person-hour
- Multiply the seed-sprint-velocity by total person-hours to get the total number of points the team should commit to in the next sprint. Continuing our example, 0.5 points per person-hour x 320 person-hours = 160 points.
total number of points committed to = sprint-velocity x total person-hours
- Now let's say the sprint is done. The team as a whole completed most, but not all of the points committed to. While their estimated velocity was 0.5, their actual velocity is different. They completed 128 points / 320 hours, so their team velocity based on the last sprint is 0.4 points per person-hour.
sprint-velocity = total number of points completed / total person-hours
- The team now has a velocity value based on their actual performance to plan the next sprint. Given the total person-hours available for that sprint, the team knows to assign a total number of points that reflects a velocity of 0.4. At the end of each subsequent sprint, the team will have another sprint-velocity sample they can use to calculate their average-sprint-velocity to plan future sprints.
average-sprint-velocity = the average velocity across the previous n sprints (where n might be 2 - 4)
Because sprint-velocity is measured in points / person-hour, it can be used with any number of team members, as well as any number of days, in a sprint. Note that Sprint 4 in the table above has 32 hours less than the previous because of a company holiday. The average-sprint-velocity can still be used to determine how many points to assign the team because it scales points based on the number of hours available.
Typically the total points a team takes on is the result of each team member contributing equal person-hours to a sprint. But sometimes a team member needs to take time off or otherwise work at a lower capacity. This is accounted for by decreasing their available hours.
If a team member will only be able to contribute to part of a sprint, their individual-commitment will be the number of hours they can commit times the average-sprint-velocity.
individual-commitment (points) = hours the team member can contribute x average-sprint-velocity
Total available person-hours is also adjusted to reflect the individual's decreased availability during the sprint.
The velocity of an individual team member is never tracked. This emphasizes focus on the collective effort of the team, not the performance of an individual team member.
Velocity tracking can over time increase the predictability of a team's output, which helps set more accurate expectations within a team. For example, the product manager can better estimate the timing of a release for a team of developers and designers with a predictable pace.
Velocity tracking can highlight the need to improve task scoping, because well-defined tasks are a prerequisite to accurate estimation. Task estimation is a difficult process but it naturally improves across sprints as the team retrospects how they estimated. By measuring each sprint against the previous, it is easier for the team to identify which areas need improvement (estimation, overcommitment, excessive blockers, etc).
Velocity tracking helps keep workloads at a reasonable amount. After tracking velocity for a few sprints a team should see a considerable improvement in comfort (i.e. committing to just the right amount of work), predictability, and consistency.