@Troy – i’ve done the measurement & predictability thing in the past and it worked well for that team in that scenario. i’m having problems applying it to my current scenario for various reasons and there is still a need to estimate at a high level, it seems. would love to continue the discussion that we started at the open spaces session :)

I think you need to ask yourself why you are estimating to start with. Estimation is not the end game. It’s about trying to achieve predictability, no?

IMHO, you can scrap all the various estimation schemes if you are really interested in improving team performance and doing it consistently. The problem is these developers are not operating in isolation. Even if you find a way to account for various skill levels, no developer can consistently predict how much they will get done in a 2 week period. If they do, then they’re padding their estimate so much it’s basically worthless. If they don’t pad their estimates, then they’re working overtime.

You have to measure team throughput and use that to make projections about where the team will be in two weeks. There are many ways to achieve this, but the key is measuring instead of guessing.
Good luck!

And yes Allison’s session was amazing, to bad u missed it :p

I do have to say that estimating based on people is a really bad idea, you are encouraging optimization of a single developer over how fast your team can complete something. Yes you may have variation between members, but I’d rather work with the likely team completion and deviation, than shunting work to the team member who gives the bet estimate.

Too bad you’re still stuck up in Waco. Don’s ideas are one of the pillars of the Lean Software Austin group. We’ve also had lots of discussion about estimation in real time and considerations for the resources and resource scheduling underpinning it.

One thing to be wary of: It appears as if the scheduling and estimation approach you’re talking about as an alternative are the same as those we had in pre-agile days. Agile’s answer was incomplete. Pre-agile’s answer was incomplete. Post-agile’s answer can be equally incomplete – especially if we just reincarnate the problems that we’ve already had by not recognizing them as they re-surface.

The resource scheduling approach that you’re proposing risks repeating mistakes that we’ve already dealt with if it’s done the same way it was in pre-agile days. Without learning organization mechanics in-play, it will create the same problems that led to it being refuted (and subsequently replaced with a naivete of agile).

How often are we asking, with anything that we do, “How is this wrong? What circumstance will make this fail? How will this fail when it fails? What am I failing to consider?”

Without the sense of imperative that leads us to check ourselves before we wreck ourselves, we’re just going to end up swinging back and forth between existing (but forgotten) orthodoxies and brand new orthodoxies. The problem isn’t the methodologies, the problem is the absence of mindfulness that whole-hog subscriptions to ideological institutions brings.

So… how will the estimation scale fail when it fails? IE: what secondary and unseen detriments can it bring? What mitigating factor changes the equation from detriment to benefit?