Recurring question among my interventions: but for heaven’s sake why not associate, bring together, replace user story points with man-days? An implication sometimes clearly expressed: it’s just “your” nutty agile mysticism, but it has no real impact, yet another marketing gimmick these user story points.

No. It is very important -in my view- not to draw parallels between *user story* points and man-days.

Why?

Man-day management is an old obsolete practice, but deeply rooted in our culture that takes us directly back to fixed-price projects and their historical lie: it would be possible to keep a three-faced promise that consists of a simultaneous commitment on date, scope, and cost. (For agile this is a notorious lie). In the field I observe that as soon as we talk about man-days this implies de facto a whole set of other particularly harmful information: a crystallization around this hydra (scope, cost, date).

Let’s imagine 2 scenarios concerning a well-intentioned manager who decides to count in man-days:

Scenario 1

He observes previous sprints and deduces an equivalence between user story points and man-days. However, during the following sprint the team commits according to his calculations to 40 man-days whereas if he observes the team’s attendance time (2-week sprint, 6 people, so ~60 days), it could commit to much more. What will the well-intentioned manager do? At minimum he will be troubled by it. And since he’s a manager his emotion has influence, this risks ending the team’s prerogatives which will have great difficulty justifying not committing “to the right level”. And that’s the end of agility. Done. Basta. We’ve fallen back into a “command & control” system as obsolete as it is harmful.

Scenario 2

A well-intentioned manager asks his team to estimate in man-days directly rather than using user story points. There, the message is immediate. How can you tell your manager that you want to commit to 40 man-days when the team has the capacity to deliver 60? The derailment is quick: either the team will inflate its estimates to make the team’s capacity and commitment coincide. Or it will actually commit to 60 days at the expense of delivery quality. We fall back into the lie of fixed-price commitment: let’s save appearances! in fact the team’s objective has implicitly changed: it’s no longer about questioning the true estimation of items, its true capacity, but about succeeding in making two values coincide (whatever the substance). We’ve lost the substance for the form. Agility is finished.

In both cases, the introduction of man-days has made estimations obsolete. In both cases, we’ve returned to a “command & control” relationship harmful to the project.

This is also why I strongly advise against using “ideal days”.

Why do the team’s estimates differ from its delivery capacity?

Because it’s very difficult to estimate in man-days, even impossible. There are too many criteria, therefore too much complexity, therefore too little predictability for these calculations to be good. In reality people who succeed in estimating in man-days don’t base themselves on a calculation, but they reproduce and draw inspiration from their past experiences, it’s agile: they reproduce a cadence they observed in a similar context. The difficulty being precisely to find a “similar context”, there are few. Very few. Very very few. On the other hand, deliverables in a project: there are many and they are present in our mind, because recent. Agile estimation is therefore heavily based on a comparison of different project elements. Is this element harder, more complex, longer to do than this one ? Comparison, and triangulation (3 elements) are the basis of agile estimation. If I introduce the notion of “man-day” the comparison is sort of poisoned. We’ve brought in a parasitic element that recalls many other constraints. The “man-day” has a rather phenomenal fatal attraction capacity. Say the word “day” or “hour”, and the person locks themselves in a trap from which they rarely emerge victorious.

Commitment is different from estimation!

I ask agile teams to disregard user story points during their commitment. They must base themselves on their feeling: this has value, because the teams have just completed several iterations of strictly identical duration. As above: we compare. And we compare what is comparable: iterations with each other, or user stories with each other, but not an iteration to a user story, and therefore the sprint commitment is a different experience than the simple sum of user story points. (Velocity can serve as an indicator, but doesn’t intervene in the commitment).

What can man-days be used for?

In both cases mentioned above (notably the first) you can reply to me: this well-intentioned manager can also not exert any pressure on the team even if he decides to count on his own in man-days and keep this information to himself? For me this scenario is extremely rare: why count in man-days AND keep the information to oneself? What would that serve? And the moment he mentions man-days, he risks making commitments and estimations obsolete. So it’s better NOT to do it.

In fact this gentleman is trying to project a plan, a release planning, to know in advance what the target scope will be for such a date in order to allow him to make trade-offs. That’s the right reason (it’s notably the product owner’s desire): are we on track? Are we within budget? Can we consider releasing this scope on this date? What scope can we release on this date given our capacity? Agile says: here’s a projection, this projection is all the more reliable as it’s based on the cadence we observed in the field, but it remains a projection. This cadence is observed in user stories or something else (potentially simply in user stories). But especially not in man-days for the reasons mentioned above.

We don’t calculate a budget with the Fibonacci sequence, sir!

I heard myself told last year: “We don’t calculate a budget with the Fibonacci sequence, sir!”

It’s true. It was a funny reply, but grounded. You want to know how much you need to commit, or how much you’ve committed, that’s normal. Nothing prevents you from counting YOURSELF in man-days. But it’s not about estimation and commitment: that’s the role of the team or teams. You can for example estimate that if we place 2 teams of 6 people for 1 year on a project it will “cost” ~2500 man-days (216*12, 216 being from memory the number of working days minus the 5 weeks of vacation in a year). We can thus project ourselves in man-days or make assessments, but as you’ll have understood we’re accounting for a commitment of means: how many people, how much time? and not a fixed-price commitment: how many people, how much time… and what scope. And the person who allows themselves to count in man-days to “budget” is not part of the team, otherwise again as mentioned above they will make estimations obsolete.

The user story point can mutate, the man-day is immutable.

Another perverse effect: the user story point can evolve over time. The team improves, it knows its scope better and better and therefore its constraints and facilities, its estimation will therefore naturally evolve. Hypotheses: what was easy at the beginning of the project we now know is hard, because we discovered the eels hiding under the rocks, conversely what was hard at the beginning of the project is perhaps now greatly facilitated (for example by all the code that was generated, by the knowledge we now have of the issues, etc.). At what point do people who want to make a link between user story points and man-days adjust their exchange rate? Rarely? so the man-day doesn’t have the right value. Often? But so if the man-day value changes constantly…

To conclude

You can determine the number of lines of code generated per iteration. By associating a rate of lines of code per day you should be able to deduce the margin generated by lot 1 of your contract if it’s not a public call for tenders and if you’re not doing offshore. Otherwise you must multiply everything by 2.75. For this last recommendation, good luck (and naturally it’s a joke… to think I feel obliged to specify…)

Flee the man-day before it devours you.

Concerning estimations themselves, I refer you to my feedback on Agile Open Sud 2012.