« Folder Hierarchies | Main | Clarification: Quatloos vs. Man-Days »

July 09, 2009


Bryan McNett

You're right, and this law of diminishing returns applies broadly to human endeavor (e.g. exploitation of natural resources:)


Hugh Hancock

This may be a dumb/previously answered question, but - quatloo? Not a term I'd heard before.

Josh Szepietowski

I am sensing a little disdain for Scrum by your choice of 'quatloos'.. :) Perhaps it is just a little confusion.

As I understand it (any 'Scrum Masters' feel free to correct) the 'by the book' implementation of Scrum:

  • Using an imaginary unit of measurement (usually called 'Story Points', but let's roll with quatloos) exists to keep honest about schedule in light of the realities of things like Drag.
  • Quatloos should be the unit of measurement from top to bottom and they are a metric for comparing work. (if A is 2 quatloos then B seems like it would be about twice as hard as A, so lets say it's 4)
  • The velocity of a team in a sprint is supposed to be measured in quatloos. This is how you arrive at the equation for how much time 1 quatloo equals. Since the velocity may change (say, from drag), the time-value of a quatloo may change.
  • "They're committing to fewer quatloos every sprint".
    • This should be reflected by decreasing velocity. What is velocity a measurement of? Work/time. What is the unit of work we are using? Quatloos. If taking on less quatloos results in higher velocity than the team is being dishonest to themselves in their velocity calculation.
  • "Measuring a project in quatloos obviously sucks, because it's so damn hard to predict how long a feature is going to take a year down the road".
    • Absolutely true and far more-so for teams recently adopting Scrum since they have less idea of their velocity. However I say it sucks for different reasons: it isn't because quatloos are imaginary units, it is because a quatloo does not have a constant real time equivalent.

      However if you estimate a project out in 'days'.. Aren't you just calling a quatloo a day? Afterall a day isn't a unit of work. A day is a unit of time. Estimating in days leads to amazing situations like: "This week we got 3 days of tasks done". If your days/week velocity changes (due to drag) doesn't this mean you need to either adjust remaining task times to the new reality?

      Personally I think this is one of the strongest reasons Scrum (and other Agile methods) have not spread faster. They reveal the truth: things are unpredictable. A Scrum team can do what a non-Scrum team does and promise X work in Y time. Is there anything about measuring tasks in days rather than quatloos that makes the process of estimating long term tasks more accurate? Less prone to fall pray to drag?

      The only difference is a Scrum team is going to have metrics screaming the reality of the situation the entire time. The reality might not be pretty.


Ah, I see your disconnect:

In Scrum, a team's Velocity is how many "quatloos" they've committed-to and completed, not the time the work actually took. It's the original "ballpark" level-of-effort estimate, not the after-the-fact time spent, that determines Velocity.

As the team gains experience working together, it's natural to see their Velocity increase by, oh, 10% or so. (It typically stabilizes around Sprint 3, and remains there unless the team make-up changes.)

Quatloo estimates do change a little as the team commits to them (I see them go down more often than up), but again, its those estimate values that, once completed, become a team's Velocity.


I'm not even sure we that I'm talking about the same thing because my experience seems mostly totally backward to yours.

It always feels (I guess I can't prove it) that speed increases in the majority of projects I've been on. The team gets used to the tools. The designers understand what works and aren't experimenting anymore. The artists know what they can and can't make. Everyone has gotten used to the system. All that stuff that was taking forever because no hard decisions had been made are now over and people are just churning out massive amounts of content and finishing up features.

I don't really see how it could be otherwise but then maybe it's a difference of perception. My perception is each month, the number of things getting done accelerates. I'm pretty sure that is objectively true for pretty much every project I've been on.

On the other hand, maybe it's a different approach. You mentioned feature creep. My experience is feature creep increases up to the first 1/2 of the project and then quickly decreases on the last 1/2 including cutting planned features there is no time for.

Simon Cooke

I'm a big fan of "be 90% done, 50% of the way through the project".

However, there's another trick.

Tell the team: If everyone is done with their work before the deadline, it's all wrapped up and put to bed, you get the remaining time to do with what you will.

Vacation? Research? Pet projects? Sure!

The important word in that sentence is "everyone" - it gets people in the mindset of helping the stragglers so it doesn't eat into their vacation time. It also makes people focus their work, and not spend time doing random silly stuff.

(And it also gets the project managers scheduling things accurately so that they don't waste money on having the office idle - mind you, the schedules need to be worker-driven in this case, or it's unfair).

The comments to this entry are closed.

Jamie's Bragging Rights

  • Spider-Man 2
    The best superhero games of all time Game Informer
    Top five games of all time Yahtzee Croshaw
    Top five superhero games of all time MSNBC
    Top 100 PS2 games of all time Official Playstation 2 Magazine
    1001 Games You Must Play Before You Die Nomination for Excellence in Gameplay Engineering Academy of Interactive Arts & Sciences
  • Schizoid
    Penny Arcade PAX 10 Award
    Nominated for XBLA Best Original Game
    Nominated for XBLA Best Co-Op Game