Early agilists already knew that time is the wrong unit to measure work. In retrospect, you can tell if a task took a week or a month, but estimations for the future are frequently off. We blame it on complexity. Or on the people involved, depending on how quick we are to judge people we have never met.

My former manager was convinced you just have to set a deadline (not only the day but the hour of the day), and the rest will take care of itself. People will pull in extra hours. He did not have a higher success ratio; his people learned to hide the ugly facts from him.

Agile introduced story points, an abstract measure of work that tells you nothing about when it will be done. All you know is that 8 story points would take twice as much time to deliver as 5. This is not the math you learned at primary school. This is advanced science with a pinch of art, and lucky stars play a role too.

Over time, agile teams tend to become more predictable. They deliver the same amount of story points every week, give or take 20 percent.

But this model still focuses on work, on drudgery. It counts how many times you lift the hammer and hit the nail. Metaphorically speaking, of course, we are programmers. We count how many web forms we have to create and how many models to refactor.

The life of a task

What has always puzzled me is the life of a task. It is a different life form than humans, giraffes, or daffodils. It does not fit into our pattern of "be born, live, and die." (However, hard Kanban boards are trying to shoehorn it into their "to do, in progress, done" columns which represent the same concept of phases of life.) You pick a task that looks fresh and yummy. You already see yourself finishing it in a day. Commit, push, and slide it to Done.

The task shakes itself and conjures up a baby task from under its cloak. It is kicking and screaming and demands attention. You have to feed it and change its nappy before you can give your full focus to its parent again. Tasks are incredibly good at spawning in the most unexpected moment. An almost finished task is no exception; it can surprise you at the last minute. (Did I tell you the story of my merge request that passed the tests and was already approved? I selected "squash commits". Instead of merging my branch, Gitlab said: "failed to merge". I hope it felt some regret.)

On lucky days, a task turns out to be trivial; it takes half of the effort you estimated. On lucky days, I say, once in a blue moon. On other days, you just hit a wall that was not there a minute ago. (Did I tell you about dockerizing a PHP application that worked on one laptop and did not on the other? We struggled to find the difference; they were almost identical Macbooks. I am still baffled by what we found: they had different chips. Think twice before you opt for an M1-based Mac.)

Plain old story points ignore these dramatic elements. They do not reflect your victory when you finally identify the chip being the culprit in the Docker case. You do not increase the estimation when you get stuck with a task. We think there is an objective measure of the complexity of any work. Human factors do not play a role in it. Whether you hate to write the tenth web form of the same kind, or you love writing a code generator for it, that is considered irrelevant.

How inhuman, you may exclaim. Or, if you happen to be a manager, you may find it professional. But this approach is totally flawed. Not on a moral ground, but for practical purposes. Programs are written by people who have moods, desires, and obsessions. Annoying factors we still have to take into account. It would be fabulous to just type in your IDE

// This is an e-commerce app supporting multiple currencies

and Github Copilot will generate the rest. The time may be close but we are not quite there yet.

Victory points

Here is my proposal. Use victory points. When you pick a new task, you state how many victory points it would be worth on completion. We can turn it into a game with play money. Imagine a rich uncle or aunt who has an unlimited source of Fixbux. How many of them would you deserve if you finish the task?

Every time you achieve a small sub-goal, you can claim a certain amount of victory points (or Fixbux, whichever currency you prefer to play with). It is up to you how many you claim. Be honest. If you think it was peanuts, claim one. If it really hurt, claim ten or a hundred. Do not be shy. Deduct your claim from the "price" you set and carry on with the work.

What happens when you hit a wall or just realize it is not going as smoothly as you predicted? Simple. You raise the stakes. You claim more. You write a little note to your imaginary uncle or aunt "I claim 5 extra Fixbux for this task because Gitlab squash commit failed. It is a pain in the pita." Remember they have unlimited resources. They will give you whatever you demand.

Remember, too, that no real money is involved, this is a game unrelated to the compensation. Cashing in more victory points will not make you rich, like winning in Monopoly will not make you a major property owner.

At the end of a period of time, you look at your transactions and see the whole story unfold in numbers. Little victories and blockers. You can track how many Fixbux land in your wallet on a daily basis. What is the average, and how much is the deviation? Your initial estimation of a task in Fixbux or victory points will improve over time.

How is this approach different from traditional story points? It is subjective and proud of it. We do not expect two developers to assign the same amount of Fixbux to a task. We want to see the personal differences represented. DevOps gives Alice goosebumps while Bob is bored to death by it? The numbers should show that.