One of the most important, but often challenging, aspects of agile product management is accurately estimating capacity and setting realistic roadmaps. Even with mature agile processes, ambiguities in scope, changing priorities, and team dynamics can make capacity planning feel like guesswork. That’s why leveraging agile techniques like velocity tracking, burndown charts, and cumulative flow diagrams (CFDs) is so invaluable for product managers. These data-driven practices provide insights into your team’s throughput and progress, enabling better forecasting.
In this post, I’ll cover actionable strategies and tools to:
- Track velocity across sprints to benchmark team capacity over time
- Use historical velocity ranges for better story point estimating
- Identify patterns and bottlenecks in workflow with CFDs
- Visually convey sprint progress via burndown charts
- Factor velocity into release planning while avoiding strict commitments
- Re-baseline velocity metrics after major changes in team or process
With the right velocity tracking metrics, product managers can objectively size backlogs, forecast roadmaps, and communicate realistic timelines to stakeholders. But velocity should be just one input into planning. Let’s explore how to supplement velocity tracking data with other considerations for successful agile capacity planning.
Velocity Tracking
Once an approach has been decided upon to estimate work required for the product’s development, it’s important to also implement a way to create a reliable understanding of how much work can be completed in any given sprint. This can be achieved by gaining an understanding of historical performance, or the team’s ’Velocity’, the term commonly used in Agile development. Historical velocity is typically calculated by summing the story point values, or other values assigned during estimating sessions, for user stories completed in the last 3-5 sprints.
By tracking velocity over time, the Product Owner can better estimate the team’s capacity for upcoming sprints and plan releases accordingly. If velocity is steadily increasing, more work can be brought into upcoming sprints, alternatively, if it’s decreasing, less work should be planned.
It’s important to note that as with estimation frameworks, Velocity isn’t an exact science and normal variation should be expected from sprint to sprint. Therefore, it is advisable to use an average, or median of recent sprints to account for this, while also watching out for major variations that may indicate an underlying change. For example, if there is a significant change in team composition, scope of work, or processes, velocity will likely be impacted, and velocity benchmarks should be reset after any such changes before re-planning occurs.
The Product Manager will need to keep an eye on throughput trends, having discussions with the team if they notice velocity steadily decreasing as this may signal problems like scope creep, unrealistic estimates, or impediments that need addressing.
Velocity forecasting can be used to tentatively plan release dates and set stakeholder expectations. But firm long-term commitments based only on velocity projections should be avoided, velocity should be only one of several inputs used for release planning. Therefore, it is important to also factor in relative priority, dependencies, risks, and scope of work yet to be done.
Burndown Charts
Burndown charts are a great way for Agile teams to visualize their velocity and sprint progress. These simple charts show the total remaining work in a sprint on the vertical axis and time on the horizontal axis. Typically, this is measured in story points or hours.
Image: Simplified Burndown Chart
A baseline is plotted to show the Ideal Velocity (burndown), where work decreases at a steady rate to reach zero by the end of the sprint. This allows easy comparison to actual progress. The Actual Burndown line plots the real work remaining based on team throughput. Gaps between ideal and actual indicate when progress is faster or slower than planned.
Burndown charts make it easy to predict whether the sprint goal will be met and how much scope may need to be adjusted. A wide gap showing Actual Burndown above the Ideal Velocity line means teams are not meeting velocity estimates. Reviewing burndown charts in sprint retrospectives helps identify patterns. A recurring late sprint crunch may indicate poor planning or inaccurate estimations.
Burndown charts give Product Managers and Product Owners insight into team workflow. For example, a dip may occur when a key resource took time off, potentially highlighting a lack of cross-training that could present future risks. Additionally, employing Cumulative Flow Diagrams (CFD) and burndown charts shows where process issues are occurring. For example, there are bottlenecks at any given stage of the planned development.
The Product Owner and Scrum Master should review their teams’ burndown charts daily and take action if needed to remove obstacles and keep the sprint on track, discussing with the team and key stakeholders to ensure risks are understood and mitigations are evaluated if necessary.
Cumulative Flow Diagram (CFD)
A Cumulative Flow Diagram, sometimes referred to as a Burn-Up Chart, is a powerful tool used in Agile project management to visualize and track the flow of work items through different stages of the development process over time. It provides valuable insights into the team’s performance, bottlenecks, and overall progress during a project.
Image: Illustration of a Cumulative Flow Diagram.
The vertical axis of the diagram represents the number of work items, such as user stories, tasks, or features. While the horizontal axis represents time. It could be measured in days, weeks, sprints, or any other relevant time unit.
The diagram consists of several columns, each representing a stage or status of the work items. Common stages include “Backlog”, “In Development,” “Testing,” and “Done.” However, the stages may vary depending on the team’s workflow. As work items progress through the different stages, they are visually represented as lines or bands in the diagram. The length of the lines indicates the number of items in each stage at a specific point in time.
The CFD is updated regularly, usually at the end of each day, or at the end of every sprint. The team records the number of items in each stage and plots them on the diagram accordingly. By observing the CFD, the team can quickly identify patterns and trends. For example, if the lines are spreading out, it may indicate a growing backlog or increasing work in progress, which might indicate potential bottlenecks. Conversely, if the lines are converging, it suggests that the team is completing work items faster than new ones are being added.
The CFD can also be used to calculate cycle time, which is the average time it takes for a work item to move from one stage to another. This information helps in identifying process improvements and estimating project completion dates more accurately.
Velocity Tracking: Conclusion
Tracking velocity and using agile metrics provide invaluable visibility, but they do not eliminate all uncertainty. Teams still need to regularly re-estimate backlogs, accounting for new complexities, and capacity changes.
However, by monitoring throughput trends through velocity and burn-down charts, and highlighting workflow issues with CFDs, product managers can get ahead of roadblocks and refine planning. Velocity tracking data enables more accurate sizing, forecasting, and stakeholder expectation setting.
Keep in mind that metrics provide insights, not absolute truths. Velocity and story points estimate complexity, not implementation time. So treat velocity ranges as informed projections, not firm commitments.
The keys are to frequently revisit estimates, smooth out data anomalies over sprints, and incorporate qualitative factors into planning. With an agile, data-driven approach, product managers can strike the right balance between stretching goals and realistic roadmaps.
The end goal is not perfect predictions, but maximizing transparency and aligning priorities to capacity. With the techniques outlined in this post, product managers can optimize their agile process to scale successfully.
Remember to keep velocity tracking metrics in perspective, use them to inform planning but not rigidly dictate it. With the right balance of data, gut instinct and frequent revaluation, your team can deliver value predictably and sustainably.
If you liked this post on Velocity Tracking you may also like:
