A race for productivity

Photo by Jonathan Chng on Unsplash

This is part of a series of articles that I am writing to share some knowledge, experiences, and points of view of things around product development and operating digital products.

This article talks to product owners, product manager, and everyone who’s part of a team that creates and maintain digital products.

A running example

I will start by sharing a numeric example of how teams achieve this plateau of productivity and gain experience after a few sprints.

Let’s consider the data in the table below. You will see that the team grows from 2 up to 7 persons across 15 sprints and at the end they are 5.

Also, velocity improves from 6 to more than 100, and IPH the index of ideal points per hour, which indicates the level of productivity of the team improve (less is better) from 25 to 5.

What’s on every column,

  • Velocity is the sum of all the points finished in the sprint.
  • People are the number of members this team have
  • Real Hours are the number of hours our team spends a day working on stuff. These are always less than office hours. 7/day per person in this example.
  • Sprints working days, are 10 days or 2 weeks in this example.
  • Man hours per sprint = RealHours * People * Sprint working days
  • IPH = Man hours per sprint / Velocity

Note that some numbers are rounded.

If you chart comparison between velocity and how many people work on the team, will look like this.

As you can see IPH improves and converges to a number around 5 for this example.

How real is this data?

As real as it gets. Of course, IPH may follow other lines but that path always converges to a number. And the reason behind this chart is the same that explains why “experience charts” looks like that. In the beginning, gains will be high, but with time improvements are smaller, or null. So in a way, this is also an experience chart.

How long does it take and what can we do to accelerate teams towards more consistent results every sprint will be the goal.

Evolving teams

Let’s dive into this problem and review again this last chart. There we can identify 3 different phases.

Phase 1 is the most chaotic. Here, team members are knowing each other, trying to understand the problem, doing a lot of onboarding to new teammates, but with poor results.

Phase 2. A team in this phase will still improve IPH in every sprint. Results are still not the best they will achieve, but feature delivery is gaining speed. All members onboard, velocity increasing, things are moving good.

Phase 3 teams have a mature process. A stable level of productivity is achieved, and velocity is high. IPH converges to a stable number, in this case around 5.

How teams evolve with time

Arguably that IPH convergence number (and its evolution) is the most important number you need to understand.

What can I do with this?

If you are responsible for leading product teams this is gold.

Now you can talk with confidence, and backed with real data, to your stakeholders. Gold.

You can replan your roadmap based on this, adding time where you now you can expect some delay, plan your quick wins, predict with more confidence when you will deliver. Gold.

Also, you can use this number to benchmark performance within your team members. See who’s leading performance, who’s behind. Make this a contest, give prizes, align the team towards added value. Again, this is Gold.

Is this number going to be stable forever?. No, things evolve, projects change, and this number too.

Now you know your goal. Make the IPH a stable and convergent number, rinse and repeat.

That’s it by now, let me know below what your think! Comments, anecdotes other points of view, everything helps and are welcome.

Btw, at some point I will talk about how to calculate velocity, which I do in a particular way, so stay tuned!

See you, next time!