New and improved — now with driving skills

Today I fought my way through the final driving test, and earned my driver’s license. I’m now allowed to drive my beloved Opel Astra at will, and so I will be driving to work every day until I can do it without thinking and/or the weather gets good enough to prefer the bike.

It took me the better part of a year, but I did it! Phew!

On to the next challenge. Hopefully something with less need for motor skill, and more computer sciency-theoretic.

Wish me and my traffic cohabitants good luck!

Annonser

Etymologi-intermezzo

Jag har funderat lite på mina etymologi-snuttar, och kommit fram till att jag är ute på hal is.

De inlägg jag har gjort har utgått från att engelskan är förlagan, och att de svenska orden har lånats in eller utvecklats därifrån.

Det slog mig häromdagen att det förmodligen är tvärtom.

Det lilla jag har läst om engelsk språkhistoria säger, om jag minns rätt, just att tidig engelska har väldigt starka skandinaviska språkinfluenser, innan normanderna invaderade landet och präglade om språket.

Hur det egentligen ligger till vet jag inte, men jag tänkte i alla fall två mina händer så gott det går.

The worst estimates are the ones you never made

I’ve become really interested in estimate techniques lately, partly because of my infatuation with XP but also because I’ve noticed that no matter how much time you spend estimating, it’s still exceptionally hard to predict a done-date with any certainty.

We’re currently trying out task planning with a point-based system for estimates.

Every task is jotted down on a sticky note, and given an estimate of either

  • 1 – trivial,
  • 2 – some work but manageable, or
  • 4 – lots of work, partly unknown.

Estimating size or difficulty rather than time makes it much easier to produce estimates with proper relative sizes.

We’ve noticed that our work rate of points/week (XP calls this velocity) is pretty constant, at around 24 points.

From the velocity, total number of estimated points and enough history, we can predict a done-date by projecting a trend that follows our extended velocity. We don’t even need that much history, in our case we’ve been predictable enough that two-three weeks has been enough.

There’s one catch I’ve noticed, though: The rate of points/week remains reasonably consistent, but the finish line — the sum of all estimated points — keeps moving.

I believe this is the primary reason why agile planning doesn’t use task estimates for long-term planning, but rather bases forecasts on feature estimates.

With task estimates, the finish line changes constantly as we discover new things we need to do to meet the scope or things that aren’t strictly necessary to get there.

If features are estimated relative to each other using a point-based system, the only way the finish line would move would be if the customer changed their mind on the scope of the project (barring a bus incident or some other unexpected event.)

After this insight, my ambition for future projects is to try and focus on breaking down requirements into valuable chunks — features — and estimating them in relative sizes.

No doubt that will prove to be difficult in other ways, but it should not cause the finish line to chase the sky, unless more features are added to the project.