As an engineering manager, I once led a traditional Scrum team, living the mainstream Agile culture. We spent hours defining, refining, and estimating work so that we could feed it into our fine-tuned productivity machine. We were all veterans of Agile Scrum — so why did it seem like this machine wasn’t as fine-tuned as we thought?
“Ro-sham-bo, throw!” our Scrum Master would shout, as fingertip estimates darted into the air. Inevitably, a few of those numbers would match, a few wouldn’t, and then the discussion would really kick off.
“That’ll take a week,” an astute engineer would offer.
“Ah-ah! That’s a measure of time and not complexity,” I would remind the group. We would then take time to recite the ethos of complexity points, before revisiting the all-too-familiar topic of developer capabilities as they related to the estimate. Back and forth we’d go, always talking about how we described the work, rather than the actual work itself.