The "story point" has gone "mainstream" with all the excesses that come with it. Let's see together how to kick the anthill, without, on top of it, getting ourselves banned from the planning and estimation sessions.

Back to the days of pre-agile estimates

Man-day / Man-month

In the world of IT project management, there is the classic "man-day". That magic unit of measurement that makes it possible to judge a team's performance, and above all each of its members, and that individually! What comfort! You just have to diligently fill in your beloved Excel spreadsheet, or any other project management tool, to see your charts update and, if needed, the alert about the team's/member's "delay".

Budget and schedule tracking is not a bad thing, quite the opposite if we want to avoid nasty surprises. But its purpose has been perverted to turn it into a micro-management and blame tool.

The corollary of this "man-day" is the "man-month", a unit used in macro-management to assess the overall workload of a project. With a project end date decided upfront, a simple division makes it possible to size the team to recruit to meet the deadlines ... in theory. That's where the very famous book The Mythical Man-Month explains at length, broadly and crosswise that this practice is not realistic. Brooks's law comes from this book, and essentially says:

• "adding manpower to a late software project makes it later"

The metaphors commonly used to explain this empirical law even better are the following:

• "Nine women don't make a baby in one month."
• "With 300 people in a kitchen to fry an egg, it won't be possible to serve the dish 300 times faster."

Confusing effort & lead time

• Effort: Time needed for the actual realization
• Lead time: Time needed before having the capacity to do it

Estimating in man-days greatly encourages the mistake of thinking that effort and lead time will be identical.

(Boss)-How long for this task?
(Doer)-Errr, 2 days?
(B) -No it isn't! I'll give you 1! See you tomorrow
(D) -But ... ( B leaves without waiting for the answer) and the 5 other tasks I have in progress, what do I do with them?

Any resemblance to real events would be purely intentional.

This confusion is an advantage if you want to keep an artistic blur around the link between the workload and its delivery. You mix 2 uncertainties that only multiply, which prompts inserting an error margin huge enough to cover any unforeseen event.

FTE

The "FTE" (full-time equivalent), is another unit of measurement, especially in fashion among project managers or directors. It's very handy, because it makes it possible to quickly assess the overall cost of a project, as well as its sizing.

Having "lots of FTEs" under your orders is a matter of pride (any resemblance to the game "who's got the biggest" would be purely coincidental). FTEs can also be used to set objectives for employees. For instance, a project manager, depending on their grade, must have between X and Y FTEs under their control; a project director between A and B, otherwise that employee is not "profitable".

This unit also has another very interesting advantage for this population. It makes it possible to hide the thinly-sliced distribution of time devoted to the project spread across different people: 1 architect at 10% + 2 devs at 60% + 2 interns (100%) + 1 apprentice (50%) = 3.8 FTE! I'll let you guess the state of the project after 6 months of V-model.

In short

All of this makes it possible to:

• separate the wheat from the chaff, the good doer from the bad, the good developer from the bad,
• build "dream teams", those teams sold at a golden price, each member having proved in their previous projects performances well above those of their peers,
• showcase the best managers with their prettiest charts, their most complex spreadsheets to detect the slightest productivity variation of every concerned doer.

The (story) point revolution

With the new project methods, estimation in "story points" appeared.

(Manager) How awful, they're removing the main productivity measurement tool!
(Doer) What a relief, they're taking away the pressure of the bad estimate to live up to!

With a view to empowering the teams and lightening the micro-management, the story point was adopted quite quickly in all organizations wanting to do agile. In the end, the transition wasn't that hard. You just swap the unit, from "md" to "point", and, icing on the cake, you can have a 1-to-1 correspondence (or any other easy-to-convert ratio).

The advantages of this new unit of measurement were clearly to break any link between the estimate produced and a possible delivery date.

The point also makes it easier to value the realization's complexity. Spending 2 days on a realization absolutely doesn't mean that the amount of code produced will be the same as for the previous realization, of the same size. But announcing 2 points makes the effort /lead time confusion much harder, if not impossible.

The focus factor

This notion is, among others, presented in the very well known Scrum and XP from the Trenches. In essence, the author explains that the point must represent an "ideal man-day", that is, a day of work without rest or interruption! Then make the quick comparison with the team's actual velocity to get a % of focus. You very logically deduce that the higher this %, the more the team is in ideal working conditions. So a large part of the team's (broadly speaking) improvement effort is often directed at improving this figure.

Can you see the possible excesses coming?

Nowadays, this notion is hardly used anymore, and this thanks to the work of coaches hammering home that the "point <=> day" correspondence is a bad practice ... rightly so.

Stepping out of your comfort zone

Now that the point is mastered, common, perverted, maybe it's time to move on. But let's not go too fast or too far — the fragile advances and the improvement momentum started with the points shouldn't be reduced to nothing by a refusal from management/the IT department/the manager who would feel even more lost.

The custom unit

We arrive at the core of this blog post.

The idea is to make a simple semantic change: drop the term "point" for… (drum roll)… whatever you want!

Yes, personalize the term! Make it your own! Play with it! Juggle with it!

Concretely, a project whose main subject is home insurance could take the term "brick". The one managing car manufacturing can quite logically take "car". So you no longer speak in an abstract unit, far from everything, but with a term closer to the business, meaningful. Knowing that projects often bear names that are not necessarily evocative, it's an element that will help better situate the project's context.

Why this (simple) semantic change?

You might retort that this tiny change will have no influence, that it's "only" semantics. You may be right in some cases, but for the others, it can change everything. It's what's called a "nudge", a "gentle push". The goals behind this idea are multiple:

• Playful: The fact of choosing your unit at the start of the project contributes to building the team and its cohesion.
• Breaking the codes: You must regularly step out of your comfort zone to explore new paths which, in the long run, can bring a lot to the team/project/company.
• Avoiding comparisons: Having the point as the unit of measurement on all projects incites, voluntarily or not, to make cross-team comparisons, to look for correlations. While it's impossible to compare cabbages and carrots, bricks and scooters.

One step further?

But let's not stop in mid-stride. Couldn't we do without the points and just keep the unit? Why limit ourselves to a single term? Why not make a full scale of values? If I reuse the previous examples, we could get something like this:

The point equivalence is only there to give an idea, but our new point scale can very well be completely decorrelated from it. I have a perfect illustration showing that this step is within everyone's reach! A well-known consulting firm has published a card deck for the poker planning that looks like this: You'll find a scale of values there, admittedly matching the classic points, but the idea is there.

Drawbacks

Of course, this solution isn't perfect, it has a few flaws, but they don't seem insurmountable to me.

• Destabilization: Yet another new assessment method! Points were already hard to adopt and use properly — here even developers will struggle to get used to it.

I wouldn't be so categorical. Sure, coaching will be needed, but in the long run it should become natural. To smooth the transition and the onboarding of new people, backing things up with a quick description of what each unit represents helps enormously. As for everything concerning tracking and forecasting, it's not so far from what was done with points; using yesterday's weather should make reasonable projections possible, maybe not very long-term, but enough as far as agile methods are concerned.

• Trial and error: How do we do it in practice? What do we base it on? Which workshop should we run?

Ask your Scrum Master or your coach, every recipe must be unique. It's not necessarily an easy practice, nor one to put in everyone's hands, but if you've reached this level, you'll know what to do.

• Tracking tools: What about my project management tool! How will it generate my charts? My burndown! My burnup!

That's indeed a trickier problem. The tools need adapting so they can exploit this kind of non-numeric scale while avoiding, precisely, clearly exposing a conversion to numeric. Right now I know only one single solution that would allow that. Visual management! Take pen and paper and do it yourself. But I agree, not easy for remote teams.

Going even further

And why not go even further? Couldn't we succumb to the seductive "No Estimate" movement? The step is still too high for many companies. That's why a first step with a unit customized for each project is an acceptable option, and one that goes in the right direction.

Conclusion

Doing agility, state of the art, is often very complicated and inconceivable for many organizations. Breaking free from "man-days / man-months" and moving to "story points" is already a good initiative, but you mustn't fall into the pitfalls described above. Once the company has acquired this culture of agility and wants to push the experience further, breaking the possible comparisons between points is a first attainable rung, without too much effort, before trying to dive into the "No estimate" bath.

PS: This text was initially written in May 2020; I deliberately left it as-is, because in the end, I still share this opinion.