2

A project manager at our company recently supplied the team with metrics for two past projects that are wildly different from one another. Based on these metrics, the project manager would like to create a baseline for future projects however, I'm finding it difficult to grasp how that would be possible because future projects could have varying degrees of difficulty, resource availability, and other issues.

Hard Project

Sprint 3.1 to 3.6 data - 6 sprints - 12 weeks   
Total Design Hours  41
Total Development Hours     250
Number of PBIs  46
Number of bugs  45
Estimate hours fixing bugs  90
Estimated hours new development 160
Defect injection rate 
(number of hours fixing bugs / number of hours developing functions)    0.56
Average team development hours completed per sprint 42

Easy Project

Sprint 2.3 to 3.5 data - 7 sprints - 14 weeks   
Total Design hours  12
Total Development Hours     124
Number of PBIs  20
Number of bugs  13
Estimate hours fixing bugs  26
Estimated hours new development 98
Defect injection rate 
(number of hours fixing bugs / number of hours developing functions)    0.27
Average team development hours completed per sprint 18

The primary concern here seems to be that the Average team development hours compeleted per sprint is around 40-50% of actual capacity and that the Defect injection rate is too high for the harder project. But these are the two fields selected to the baseline for future projects. But what does this mean exactly? How can you arbitrarily just select the metrics from one of these projects and apply them to a future project? After looking at this question What is the best way to develop a project baseline? it looks like we might be conflating different ideas.

  • 2
    Generally speaking, the velocity of different teams is not directly comparable. Understanding what is being measured, and what you're attempting to predict, is essential to making even a wild guess based on insufficient data. – Todd A. Jacobs Jul 11 '17 at 0:50
1

It depends significantly on what is said baseline's purpose. One approach, based on the concept of Bayes's Theorem (the sun rose yesterday, and the day before, and the day before..., so it is pretty likely it will rise tomorrow), would involve aggregating all previous projects in order to obtain a continually-improving baseline.

In which case, since you currently only have two data points, your original baseline won't be very useful. After a third project, you update the baseline, and it becomes a little more useful. After the fourth, fifth, etc., the baseline continues to improve, eventually become a decent predictor for the 'average' project's success. While this is a somewhat naive method (as it ignores variance in project size and type), it is at least low in complexity.

If, however, your project manager just wants to throw these two data points at you and receive in return an accurate and precise predictor of project schedules for all future products... They're likely to be sorely disappointed.

First try to figure out what this baseline will be used for. That should help you either figure out how to create it, or figure out that it shouldn't be created in the first place (in which case your task becomes convincing said PM of your finding).

  • 1
    If you have a very high variance the average will be useless – DesignerAnalyst Jul 12 '17 at 7:01
  • 1
    @DesignerAnalyst Assuming that all the projects form something similar to an even distribution, true. If, however, they form something similar to a standard distribution (which, in my experience, is more common), then assuming a large enough sample size, your baseline can still become helpful. – Sarov Jul 12 '17 at 13:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.