Stop Guessing, Start Measuring
One of the most common mistakes in software project planning is using assumed or ideal numbers for team velocity and utilization. We often hear statements like:
- “Our developers are 80% utilized”
- “Each team member completes 10 story points per week”
- “We’ll be 100% productive after the first month”
- My personal favorite, “there’s no way that a 60% utilization is correct!”
Reality tells a different story.
What the Data Shows
Several years ago before the concepts supporting the Red Line Burndown crystalized, we were on a deep personal mission to understand what was driving inaccuracies in our ability to predict projects. One of the first data-driven metrics that we looked at was utilization. When we refer to utilization, we’re thinking about it in the classical project management sense – what percentage of the time are our teams actually working on the project. We made assumptions like Software Engineers work 8 hours per day, 5 days per week.
The reason we chose utilization was that we thought that it would be reasonably easy to measure (assuming we could get our software engineers to track it). At many companies the thought track was “we’ll just have them fill out timecards.” We knew that would likely immediately fail for all the typical reasons and instead focused on building an ecosystem that would create a closed loop project management process.
If we could track time using Jira with reasonable discipline (maybe to 10% accuracy) and share that data with the team, then perhaps we could create a system that would allow developers to learn about how to create better estimates. Initially we used rather rudimentary methods to review developer actuals (logged against Jira tasks) and over time started looking at larger datasets from many teams. Here’s what we found…
Utilization Reality
- The average team utilization rate is closer to 60%, not the often-assumed 80%
- When we dug deeper, we realized that developers were decent at estimating the amount of time it would take to complete a task; however, they weren’t great at estimating how much time they would have to spend on a task.
- We broke the problem down by looking at the average time spent on vacation, company holidays and to corporate requirements like training, company meetings, etc. This was typically 10-15% of each developers time.
- That left 85% of the developers time for project work. Within a project, we observed that roughly 60% went to requirements, design, coding and testing activities, another 15% went to project overhead (project meetings, project planning, etc) and rest went to team or department activities.
- Utilization varies significantly throughout the year, with predictable dips during holidays and summer months. The best quarter of the year was always Q1 from January -> March because many folks had just taken a significant amount of vacation for the holidays. Q2 & Q3 were not quite as good as Q1 due to summer vacations. And the quarter with the lowest utilization was Q4.
- Context switching can reduce effective utilization by up to 20%
- When planning projects, ramping costs are expensive, so we aim to ramp up a developer as quickly as possible and then have them leverage that knowledge for as long as possible.
Velocity Patterns
- Team velocity typically takes 3-4 sprints to stabilize for new projects
- Individual developer velocity can vary week over week
- Teams consistently overestimate their velocity or utilization when not using historical data
Why Measuring Matters
Using real data to determine velocity and utilization rates leads to:
- More Accurate Planning
- Resource models based on actual performance, not optimistic guesses
- Better prediction of project completion dates
- Realistic capacity planning
- Improved Team Health
- Sustainable pace of work
- Reduced burnout
- More accurate sprint commitments
- Better Business Decisions
- Realistic project quotes and timelines
- Informed staffing decisions
- Clear capacity constraints
How to Measure Effectively
The Redline Burndown Gadget provides several key metrics:
For Story Point Projects
- Weekly velocity per person
- Velocity trends over time
- Impact of team size changes on overall velocity
For Time-Based Projects
- Actual utilization rates
- Time spent vs. estimates
- Resource efficiency patterns
Common Pitfalls to Avoid
- The Utilization Myth
- Incorrect utilization assumptions lead to burnout and decreased quality and unrealistic timelines
- Buffer time is essential for learning, collaboration, and handling unexpected issues
- Ignoring Historical Data
- Past performance is the best predictor of future performance, so start by baselining your team’s utilization or velocity
- Team velocity stabilizes over time for a given project
- Historical patterns reveal systemic issues
- Not Accounting for Context
- Different types of work have different velocity patterns
- Team composition affects overall productivity
- Project phase impacts velocity (start-up vs. maintenance)
Recommendations
- Start Tracking Now
- Use tools like the Redline Burndown Gadget to capture actual velocity and utilization
- Track trends over at least 3-4 sprints
- Review and adjust regularly
- Plan Conservatively
- Start with 60% utilization for new projects (and if you’re using story points, then do some rough math over at least one quarter to determine actual velocity)
- Use the lower end of your velocity range for initial planning
- Build in buffer for discovered work (typically 20-30%)
- Communicate with Data
- Share velocity and utilization metrics with your team and stakeholders
- Use actual data to justify resource needs
- Demonstrate improvement trends over time and measure the results
Conclusion
The difference between successful and struggling projects often comes down to how well they understand and use their velocity and utilization data. Stop guessing and start measuring. Your teams, stakeholders, and project outcomes will thank you.
Remember: The goal isn’t to maximize these metrics but to understand and work with them realistically. A sustainable pace based on real data leads to better quality, more predictable delivery, and healthier teams.