A Capacity-Aware Parr Model for Agile Projects
This paper proposes a capacity-aware refactoring of the classical Parr model that integrates normalized latent effort demand with observed or planned capacity trajectories to forecast agile project progress, completion time, and resource deficits without assuming unrestricted staffing.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you are planning a long road trip. You have a map that shows exactly how much fuel you should burn at every stage of the journey to get there on time. This is what traditional software models do: they draw a curve saying, "To finish this project, you need a huge team in the middle, fewer people at the start, and fewer at the end."
But here's the problem in the real world (especially in "Agile" software teams): You don't get to hire whoever you want, whenever you want. Your company has a fixed team of five people. Maybe they can only work 40 hours a week. The traditional map says, "You need 20 people next month!" but your boss says, "Nope, you only have five."
This paper proposes a new way to look at that map. Instead of treating the curve as a strict rule for hiring, it treats the curve as a hidden hunger for work.
The Core Idea: The "Hunger" vs. The "Fridge"
The author, Pedro Colla, suggests we separate two things:
- The Hunger (Latent Demand): This is the "Parr Curve." It represents how much work the project naturally wants to get done at any given time. It's like a stomach that gets very hungry in the middle of the day and less hungry in the morning and evening.
- The Fridge (Capacity): This is what you actually have available. Maybe you only have a sandwich (5 people) when the stomach wants a steak (20 people).
The Old Way: The old models assumed that if the curve says you need a steak, you must get a steak, or the project fails. They tried to force the team size to match the curve.
The New Way (This Paper): The new model says, "Okay, the project is hungry for a steak, but we only have a sandwich. We will eat the sandwich. We will get as much done as the sandwich allows, but we won't pretend we ate the steak."
How It Works in Plain English
The model uses a simple math formula to track this "hunger." It asks three questions:
- How big is the whole meal? (Total effort needed).
- What does the hunger curve look like? (When is the project usually busiest?).
- What is in the fridge today? (How many people are actually available this week?).
The model then calculates:
- Progress: How much of the meal did we actually eat this week?
- The Gap: Did we have a "capacity deficit" (we were hungry but had no food)?
- The Slack: Did we have extra food in the fridge that we didn't need to eat?
The "Rolling Forecast" Analogy
Imagine you are driving and checking your GPS.
- Old GPS: "You must drive 100 mph to arrive at 5 PM." (Ignores traffic or speed limits).
- This Model: "You want to drive 100 mph to arrive at 5 PM, but the speed limit is 60. So, you will arrive later. Let's recalculate your arrival time based on the 60 mph limit."
The paper tests this idea using data from a real software project (a team of 5–8 people working for 22 weeks). They split the data in half:
- Calibration: They used the first half of the trip to tune the "hunger curve" to fit that specific team.
- Prediction: They used the second half to see if the model could predict the future based only on the team's actual size, without peeking at the final results.
What They Found (and Didn't Find)
The paper is very honest about what it achieved:
- It works internally: The model successfully tracked the team's progress and identified when they were "starving" (not enough people) or had "leftovers" (extra capacity).
- It's simple: It doesn't try to explain why the team is slow (like bad communication or bugs). It just measures the gap between what the project needs and what the team can do.
- It's not a magic crystal ball: The authors admit they only tested this on one project. They cannot say it will work for every company in the world yet. They need to test it on many more projects to prove it's a universal rule.
The Bottom Line
This paper doesn't invent a new way to build software. Instead, it invents a better dashboard for managers.
It stops telling managers, "You must hire 20 people!" and starts telling them, "The project is hungry for 20 people, but you only have 5. Here is exactly how much slower the project will go, and here is exactly when you will finish if you keep the team size at 5."
It turns a rigid mathematical curve into a flexible tool that respects the reality of limited resources.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.