The point count method is a way to estimate the effort required to complete a software development project. It assigns a numeric value, called a story point, to each item of work, or user story, in the project backlog. Story points represent the relative level of effort required to implement a user story compared to other stories.
How does the point count method work?
With the point count method, the development team estimates the effort for each user story during sprint planning meetings. The team assigns a story point value based on the estimated complexity, uncertainty, and amount of work required. There is no specific formula for assigning points – the values are comparative within the project context. For example, a story worth 3 points requires three times as much work as a 1-point story.
Some common point scales used are the Fibonacci sequence (1, 2, 3, 5, 8, etc.), powers of 2 (1, 2, 4, 8, 16, etc.), or a simple numeric scale like 1 to 10. Once the team assigns story points, the total number of points committed for a sprint represents the team’s velocity – how much work they can complete in that timeframe. Over multiple sprints, velocity averages enable reliable release planning and forecasting.
What are the benefits of using story points?
There are several key benefits to using the point count method instead of time estimates:
- Points are more accurate – time estimates are often wrong, while complexity relative to other stories is easier to estimate.
- Velocity stabilizes – velocity based on points is less volatile sprint-to-sprint than time-based velocity.
- No false precision – points communicate level of effort, not duration. Time can imply false precision.
- Accounts for unknowns – points factor in ambiguity, complexity, new skills needed.
- Velocity can be compared across teams – point scales provide a normalized metric of productivity.
How are story points estimated?
Teams use techniques like planning poker, bucketing, or affinity grouping to estimate story points. For example:
- Planning poker – Each team member privately selects a point value, then reveals simultaneously. Differences are discussed and values adjusted until consensus is reached.
- Bucketing – Quickly categorize stories into buckets like XS, S, M, L, XL representing increasing point values.
- Affinity grouping – Group similar stories together, compare relative effort between groups to estimate points.
The goal is to arrive at a point value through discussion and consensus among the team. Factors to consider include:
- Level of complexity and unknowns
- Amount of work/tasks involved
- Dependencies on other stories or components
- Whether specialized skills are required
- How much clarification or details are needed from PO
- Comparative effort versus other stories
What are some point count estimation best practices?
Some best practices for effective point-based estimation include:
- Involve the whole team – multiple perspectives improve accuracy.
- Estimate frequently – estimate during backlog grooming and refine estimates as needed.
- Estimate relatively – focus on comparing stories to each other rather than absolute values.
- Re-calibrate regularly – review differences between estimates and actuals.
- Use historical data – leverage completed stories to estimate similar new stories.
- Estimate in small batches – avoid big upfront guesswork.
What are some common estimation pitfalls to avoid?
Some key point estimation mistakes teams should watch out for:
- Anchoring on previous estimates – don’t let old estimates influence new ones.
- Estimating based on solution rather than problem – focus on what, not how.
- Gaming the system – points should not be inflated to reduce commitment.
- Disagreeing without discussion – have conversations to arrive at consensus.
- Changing point scales – maintain a consistent scale for meaningful velocity.
- Comparing teams – each team’s points are calibrated differently.
How do you create a velocity chart with story points?
To create a velocity chart using story points:
- Record total story points committed for each sprint
- Track actual story points completed at the end of each sprint
- Enter these values into a velocity chart with sprints on the x-axis and points on the y-axis
- Draw a trendline through the sprint data points
- The chart’s slope indicates average velocity across sprints
An upward sloping line shows improving velocity, while a downward slope may indicate problems. The chart can also forecast release plans based on the team’s velocity.
Example velocity chart
| Sprint | Committed Points | Completed Points |
|---|---|---|
| 1 | 50 | 38 |
| 2 | 60 | 50 |
| 3 | 55 | 53 |
| 4 | 63 | 60 |
| 5 | 55 | 55 |
How do you determine team velocity from story points?
To determine velocity based on story points:
- Add up all the completed story points from past sprints
- Determine the total number of sprints
- Divide total completed points by number of sprints
For example, if a team completed 200 points over 10 sprints, their average velocity is 200/10 = 20 points per sprint.
For a new team with no historical sprints, they can benchmark velocity from other teams or estimate their capacity. As sprints are completed, the rolling velocity average becomes more reliable.
Should you include partially completed stories in velocity calculations?
Partially completed stories should generally not be included in velocity calculations. Velocity is the amount of work a team can complete in a sprint, so only fully finished stories count.
However, if a large portion of a story is complete, the team may decide to award partial points to credit that work in velocity. For example, if a 5 point story is nearly done with just small items remaining, they may count it as 4 points complete.
What is an ideal velocity range?
There is no universal ideal velocity or velocity range. The optimal velocity depends on team size, sprint length, and work context. Smaller teams will have lower velocities, while larger teams can achieve higher velocities.
A good target velocity range is 50-80% of a team’s maximum capacity. If velocity is below 50%, the team may be overcommitted. If velocity continually exceeds 80%, the team may be taking on too little work and have unused capacity.
Velocity varies naturally sprint-to-sprint due to changing scope, unplanned work, and other fluctuations. The goal is a consistent long-term average in the target range.
Can you have velocity of 0 in a sprint?
Yes, it is possible for a team to have zero velocity in a sprint if no user stories are completed. This likely signals a problem with the sprint execution.
Some common root causes of zero velocity include:
- Incorrect workload estimation and overcommitting
- Unexpected blocks or dependencies
- Team members pulled off sprint work onto other tasks
- Poor breakdown of stories and tasks
- Insufficient skills to complete work
- Stories not “ready” or poorly defined
If velocity drops to zero, the team should hold a retrospective to understand what prevented story completion and create a plan to get velocity back on track.
How do you deal with uncertain or partially completed work in story points?
There are a few options for dealing with uncertain or partially completed work when using story points:
- Carry over points between sprints – If some amount of work carries over into the next sprint, only count the newly completed portion in the second sprint’s velocity.
- Award partial points for progress – Credit some percentage of story points based on work finished.
- Keep story open across sprints – Don’t count any points until the story is fully complete.
- Split story – Break large uncertain stories into smaller chunks with clearer scope.
The approach depends on the team’s context and policies. The key is to be consistent in how velocity and story completion are measured.
What is velocity variance and why does it matter?
Velocity variance measures the variability or volatility between sprint velocities. It is calculated by comparing each sprint’s velocity to the long-term average velocity.
Lower variance is preferred for predictability. High variance means velocity fluctuates greatly between sprints, making it hard to predict. Causes can include:
- Frequent requirement changes
- Poor estimation discipline
- Inconsistent work focus across sprints
- Team members added/removed
- Too much unplanned work
Addressing these issues can reduce variability. Some level of variance is normal, but monitoring the metric helps ensure smooth predictability.
What does a change in velocity over time indicate?
Trends in velocity over multiple sprints can reveal useful insights into the team’s workflow and capacity:
- Increasing velocity – The team is becoming more productive, efficient, and skilled at estimating and executing work.
- Decreasing velocity – The team may be overloaded, facing roadblocks, or impacted by changing priorities and scope creep.
- Volatile velocity – The team likely has poor estimation practices or frequently interrupted sprints.
- Steady consistent velocity – The team has achieved a stable and predictable pace of work with good estimation practices.
Velocity trends over 10+ sprints provide the most meaningful insights. An improving or steady velocity is ideal for most teams.
How often should you re-estimate story points?
Stories should be re-estimated if new information emerges that significantly alters a story’s scope. But in general, excessive re-estimation should be avoided.
Some best practices on re-estimation frequency include:
- Lock estimates after sprint planning for commitment
- Revisit during backlog refinement if major design changes occur
- Re-estimate any carry over stories in the next sprint planning
- Analyze stories that were frequently re-estimated to improve estimation capability
- Avoid re-estimating for gaming the system or reducing team commitment
Estimation is imprecise by nature. Some re-estimation is expected, but excessive changes indicate problems in story clarity, planning rigor, or team skills.
Can you apply story points to non-software projects?
Yes, the concepts of story points and velocity can often be applied to non-software projects as well. Instead of user stories, the “stories” would represent units of work relevant to that project, for example:
- Research projects – experiments, simulations, surveys
- Marketing campaigns – website pages, promo materials, events
- Process improvement – new workflows, trainings, systems
The project team would estimate effort levels for project components in story points, track velocity, and use it to forecast schedules. The methodology works for any project that can be broken down into quantifiable units of work.
How are story points used for planning and prioritization?
Story points help inform planning and prioritization decisions in a few key ways:
- Gauge level of effort – Points communicate complexity for priority and sequencing
- Project required time – Velocity helps estimate total time to deliver stories
- Benchmark productivity – Velocity shows rate of output for future planning
- Identify bottlenecks – Point density exposes high complexity areas
- Right-size backlogs – Velocity helps size backlogs to team capacity
For example, a 50 point per sprint team could deliver a 150 point backlog in approximately 3 sprints. Story points provide crucial context for planning at multiple levels.
Conclusion
In summary, the point count method provides software teams with a useful metric for estimating work, measuring velocity, and planning projects through an agile approach. Assigning story points to backlog items enables tracking team productivity, exposes uncertainty, highlights bottlenecks, and improves predictability through velocity trends. With some experience, point-based estimation can create a shared understanding of work effort to help teams effectively scope, prioritize, and deliver maximum value.
