Software Team Benchmarks For Better Project Planning

Do you know how your software development team stacks up in productivity, efficiency, and output?

While we aren’t into keeping up with the Jones, knowing how other teams perform can help you improve your planning and estimations.

Here at 7pace, we’re all about using data to understand how your team works and generate insights to help developers become more effective.

We have pulled samples from datasets of hundreds of companies and thousands of developers worldwide who use 7pace to track their time to see how software teams plan their work and work their plans. Here’s what we found out:

How Many Hours Do Developers Work Per Week?

After omitting outliers (e.g., the first week of January when most people took time off,) we found that most developers spend 31-32 hours per week on software development related tasks.

When estimating your projects, it isn’t realistic to expect developers to dedicate 100% of their time to software development related work items. Team members need to spend time on other tasks (e.g., administrative or management work) to ensure that projects go smoothly.

When planning your sprints, leave some time (say, 5 to 10 hours per week) for non-coding and non-billable activities to avoid delays or unnecessary pressure.

We also found that productivity varies throughout the year (e.g., when people take summer vacation,) so you should account for these fluctuations when planning your sprints.

You can use historical data to understand the ebb and flow of your team’s availability and productivity. Then, leverage the insights to ensure that your project plans are realistic and your estimates are accurate.

What’s the Average Number of Story Points Per Sprint?

Most teams complete 1 to 45 story points per sprint. Then, the number tapers off into a long tail to over 1,000 story points per sprint, which accounts for 4% of our sample.

Every team has a different approach to calculating and planning with story points. Even though there are some general patterns, there’s no one right answer (e.g., how many hours of work correlate with one story point.)

The value of a story point is subjective. You can’t convert it across teams. The only way to understand what one story point means for your team is to track the actual time spent on each work item and compare it with the estimate to see how much time you need to complete one story point.

Then, you can use this insight to inform future estimates. The more iterations of this process you go through with the same team, the more you can refine your estimation techniques, the more accurate your planning process will become.

What’s the Average Number of Hours Spent on a Work Item?

To answer this question, we analyze the average number of story points per work item (or user story) and the average number of hours worked per item. Then, we divide the number of story points for each work item by the hours spent completing it to calculate the team’s pace.

Again, we got results ranging from single-digit to almost 125 hours per work item, illustrating how teams chunk up their work differently, and there’s no one right way to plan a sprint.

When we calculated the average pace, we found that teams spent an average of 4 hours on one story point. But the number varies widely—pointing to the fact that there’s no one right way assign story points.

Around 22% of the projects in our sample didn’t use story points as an estimation technique, further illustrating that there are many ways to estimate a project, and understanding how your team works is the foundation to success.

Insights From Software Team Benchmarks: What We Learned

Our data gives us insights into how to plan and estimate software development projects.

Teams work differently, and story point is a subjective measure that equates to different levels of effort or number of hours for different developers.

So how can you tell if your team is making improvements or staying on track during a project? You need to set internal benchmarks.

First, establish a system and use the right tools to track the time developers spend on each work item. Then, divide the hours by the number of story points assigned to the item to calculate the team’s pace.

You can use the team’s pace to inform future planning (e.g., calculate how much time a work item will take based on estimated effort.) You can also check your pace during a sprint to identify issues early and course-correct if it’s going much slower than expected.

7pace Timetracker enables developers to track time where they work (i.e., on Azure DevOps or GitHub) and associate the time they spend with each work item. You can also pull granular reports in real-time to track progress.

Try 7pace to get the data you need to create your internal benchmarks and better understand your team’s work and performance.