When you're a development manager, metrics are often one of the key things everyone wants you to provide. I'm firmly in the camp that believes metrics matter. While I don't go so far as to agree with "if it can't be measured, it can't be managed" (a misquote/misattribution, by the way), I do believe that many things can be measured and that does help you manage those things.
The most obvious metric that we look at is the team velocity, usually measured in points-per-sprint. I'll get to that in a later post and I'm going to assume the reader has a general understanding of story points.
Points-per-Dev-Day
Today, I'd like to talk about Points-per-Dev-Day aka PDD. This simple metric provides great information while removing a lot of noise. Simply put, this is the number of story points the team delivered divided by the number of developer days available.
Scenario 1: Your team has 5 developers and 9 working days in the sprint. That's 45 developer days. The team delivers 40 points. 40/45 = .89 PDD.
Scenario 2: Your team has 5 developers and 9 working days in the sprint. 1 developer has a 2-day vacation. That's 43 developer days. The team delivers 40 points. 40/43 = .93 PDD.
Measuring Efficiency
PDD is a measure of the team's efficiency. It shows how many points, on average, the team is delivering for each day of the sprint. This can be used to predict the velocity of future sprints and assess the overall health of the team. It can also be used as a goal for deciding sprint capacity.
Let's take our team of 5 developers from above. They've been averaging .9 PDD for the last three sprints. However, for the coming sprint, one of the developers will be out for 4 days. We can use that info to give guidance on how many points they should pull into the sprint. With 41 developer days available we can suggest the team take on around 37 points in the upcoming sprint. 41 * .9 = 36.9.
Of course, this is just a guideline. I've had teams take 12 points more than was suggested because they felt they could deliver on all of it by sprint end. Ultimately, the decision on the sprint capacity is up to the team but the PDD metric is a useful tool for estimation.
Why Only Devs
I explicitly exclude the QA engineer's (and others) time from this metric. Typically, developers are the starting point of working on a story. They're laying down the first code changes. QA is usually downstream of this and, thus, is dependent on the devs for work. If I were running a team comprised exclusively of QA engineers, I'd use the same metric but base it on their capacity. By restricting this metric to being based on the developer's capacity, efficiency is measured more by the start of the pipeline than the middle or end.
Target Range
Every team is different and every environment is unique so there's no hard and fast rule. Generally, I try to get my teams to aim for 1 PDD. I've found this is a good level of efficiency when all things are taken into consideration.
If you find your team is hitting above 2, you may want to look at your estimation process and how much dev time your larger story point items are taking. Is your team consistently knocking out 3-point stories in under a day? Maybe those should be 2 or even 1-point stories.
I'm not advocating for arbitrary point deflation. A team should decide for itself what their point values and criteria are. I'm simply suggesting that if a 3-point story can be actioned in under a day, it doesn't leave a lot of room for 1-point stories and the team's velocity might be a bit inflated.
Conclusion
There are several metrics that are important as a dev manager. Too often, we get hung up on velocity and ignore others that might be more meaningful. Points-per-Dev-Day is a metric I find useful as it shows me the efficiency of my team vs their overall output. When I combine it with other metrics, it gives me a good picture into the performance of my team and helps me identify areas where improvements can be made.
Comments