Why an honest ledger matters

About a decade ago I was working on a project that had all the proper pins in place. A PM who knew his trade and all the certificates. An experienced team, everybody reliable. A solid plan, well resourced and comprehensively laid out. It failed, utterly and totally, to the point that it never saw the light of day.

Did the market change, the goals, the plan? Nope. Did it run out of funding, or get superseded by some other project? No again.

It wasn't until a short, brutal round of forensics that the truth told out. The main culprit was individual tasks had bloated from within, either by low initial estimation (it just took longer) or through persistent evolution of "finished" (the old decided by committee routine). The overall goals hadn't changed, it was the same feature set, but each pass required "just one more round" to "make it perfect".

Throughput and Velocity remained strong. The stand-ups magically reshaped themselves around the expanded number of tasks. Three-day tasks spawned two-day rework. Milestones shifted, then rotted. Everybody was working hard, all the charts said so. But Throughput and Velocity measured by # of closed tickets is meaningless when the "next" ticket was just a new version of the "last" one.

What they decided was: everybody worked hard, everything was on track, sometimes things just don't work out. Random blame was assigned one or two levels below where it belonged. The company shrugged its shoulders; everybody had already moved on to the next job.

The thing that amazed me was, the forensics changed nothing. Not a single institutional change was made, no recommendations filtered down to the team, no production-level changes came into being. What it came down to was this: nothing in any of the project reports or charts showed a problem. Tickets closed, work got done and nothing threw up a flag that things were going south.

It was a bit crushing, to be honest, because we had all felt it slipping almost from the go. More meetings, tighter deadlines, longer hours, but nothing in the charts ever changed. That was the thing that broke me, that vast distance between the thing we saw and the thing the progress report told us. In hindsight, I think it was that project that inspired AbleTime.

Reports built for comfort

I now realize that the core problem was how we measured progress. Every task had been graded loosely by complexity (nothing so formal as Story Points). Off that, it was guesstimated how long it would take, usually measured in days, to complete. If one task ended up being task+rework, it perversely increased our throughput because we closed two-for-one that sprint. We tracked hours against the work, but only in prose. "5h on T-232, 40% complete, building out the ui".

The spread between "estimated effort" and "actual effort" was never measured because one was a guess and the second was a finish date. There's no ruler for that.

If we'd had AbleTime, every one of my time entries would have been attached to T-232, and T-232 would have a little box of estimation that would have been slowly consumed. 12 of 20h used. 17. 31. 40! We didn't, so the task was just a "Large".

Velocity can not be measured by completions, because "completion" is a moving target. "Done" is only true if it shipped instead of spawning T-234.

In many modern workflows, there is no cap, or if there is ... the cap is theoretical. This task is "Large", and as a "Large" it will take "A While". The number of "Small" up to "Large" tasks closed is measured by simple formula, and that gives you Velocity.

Pseudo Velocity: 4S + 2M + 1L = 4 + 16 + 24 = 44 (goal: 40)

If your goal is 40, then yay! If the milestone was missed, see 40 yay! It really isn't much more sophisticated than this. It is a system built for comfort and convenience. Your effort can never 'exceed' Large, not really. And what is Large in the fintech project you worked on last week compared to the bakery blog project this week? Large is subjective, relative, and ultimately meaningless.

If the task was instead "estimated: 30h" then "completed in: 20h", or "completed in: 42h", you have a real measurement to hang your progress upon. Meaningful questions fold out: is this one under-estimation, or a pattern; if the latter, are we wasting cycles in the doldrums or taking advantage of the early wins? Why did we go 12 hours over estimated; is overhead interfering, or was the task under-specified? With only "Large", we have nothing to pin these variations on.

"Small/Medium/Large" came into being because subjective work is supposedly impossible to estimate accurately. In 30 years of development, I never once met a developer who didn't mentally convert a given "T-shirt" sized task into hours or days. Complexity may be arbitrary, but measuring the arbitrary is what professionals do across every profession.

The ruler

It comes down to two things: scale and drift.

Projects, or possibly Epics, are the smallest unit of scale you can measure with a very loose system. Those are where the milestones live, hard deadlines that either pass or fail. It's the marker of "this launches here or we guessed wrong". It is a very wide target to bet your house upon.

Measure in hours and the scale changes. Velocity and Progress live at the task level, instead of the project. "Large takes a while" is comfort while "Task X exceeded its estimated hours by 30%, so we need to adjust our plan". The scale of the loose system is too large to make meaningful adjustments, until it is already too late.

To borrow a little from a finance idiom: smaller measurements mean earlier signal.

Drift is this: time moves in one direction, and effort is linear across time. The goals are the same, the milestones are the same, but within them you immediately see the drift in your estimations. If every task is 20% under-estimated, then the bars will glow red and shove everything else forward, but more importantly you will immediately understand why on day ten, you're going to miss a milestone pinned to day sixty.

Built for honesty

If we'd used AbleTime a decade ago on that ill-fated project, I can't honestly say if it would have saved it from the digital trash heap, but I do know we would have seen the drift much earlier on, read the bloating tasks as under-specified and under-estimated, and been able to better adjust our direction and our agenda.

Hours don't lie. Witnessing them overflow every task and shove work beyond the earliest milestones is an easy tell that something's amiss. Instead of forensics gleaned from emergency stand-ups, the team is observing reality-grounded graphs and making informed adjustments, then adjusting again until the system is tuned and the actual velocity matches expectations.

We're early days, but already we are seeing the shift. AbleTime isn't built for comfort, unless comfort means sleeping at night because your reports can be trusted. We're built for honesty, because it moves you from feeling informed to being informed.