Building products and features is hard.

There are far too many moving parts, several people get pulled in to build it, and there is this uncertainty over where things stand.

And to top it all, there are no benchmarks or metrics that we can compare with to see how our team stacks up against others.

At Zepel, we spent several hours looking at how 1200+ teams of several sizes build products and features using Zepel. Here’s what we noticed.

1. Break down of how teams plan their features

When teams spec and plan features, they create nearly an equal number of user stories, tasks, and subtasks at 27%, 32%, and 31% respectively. Bugs and enhancements, however, take up just 4.75% and 3.2% of the total.

A graph of how teams plan features
A breakdown of how teams plan their Feature

2. How long does it take to complete a feature?

Ever been bombarded with the question of how long it’ll take for the feature to ship?

On average, it takes 19 days for an entire feature to get completed when there is an average of 15 items in a feature. However, it takes 23 days to complete the complete feature when the average number of items in a feature increases to 38.

A report of how long it takes to complete a feature
It takes only 4 extra days to complete a feature that is 2.5 times bigger than the others.

It’s not surprising that the average number of days increases as the amount of work increases. But when we compare the two, it is evident that it takes just 4 extra days to complete 2.5x more work.

What caused this increase in 2.5x productivity?

When we took a closer look, we noticed that this increase in productivity was backed by three key points:

a) When the feature takes 19 days to complete, a sprint had an average of 17 items. However, for teams whose productivity increased by 2.5x, we noticed the average number of items in a sprint increased to 31.

All of this while the average sprint duration remained the same at the recommended duration of 2 weeks.

A report of how many items are added to a Sprint to complete a feature
Teams that had more items in the sprint managed to complete their feature quicker

b) Teams that completed 2.5 times more work in just 4 extra days had 3x more subtasks per feature. This allowed teams to break down their work into smaller chunks and estimate user stories more accurately.

Report of average number of subtasks added to plan and complete a feature
The team that completed a bigger feature also had 13 times more subtasks

c) We know collaboration is important. But how important is it to build a feature?

We noticed that teams that completed their feature in 23 days with 2.5 times more work items had 12 times more comments per feature. This allowed teams to collaborate and hand off work better.

Productive teams in Zepel saw an increase in comments in 12 times
Teams that worked on the bigger feature had 12 times more comments per feature

3. Product Development Has Plenty of Moving Parts

Of course, teams aren't just building Features using Zepel. After all, unexpected bugs creep up out of nowhere, high-paying customers will want an improvement to be made on an existing feature, and of course, new feature requests will keep coming in.

Teams using Zepel add smaller user stories, unexpected bugs, and miscellaneous tasks to the project’s List, prioritize them, add them to a Sprint when they're ready to work on it or just track them on their Dev Board.

54 percent of all work items were created to plan features
46% of all items created were added to the List.

Final Thoughts

  • Product teams experience invisible loss in their business due to inefficiencies in their product development efforts.
  • 82% of the customers leave due to poor experience. 14% of that is because the product/service didn’t meet their expectations according to a research by The American Society of Quality Control.
  • Since product development is a multi-disciplinary effort, current project management tools barely cut it. Nearly 56% of all product and project managers are on the lookout for a new tool every year. According to Software Advice, the primary reason is because they need a more robust solution (37%).

The goal of this report was to help you understand how others build products and how your team stacks up against them. That way, you can identify and remove inefficiencies from your entire product development process and proactively satisfy your customer's needs.