Agile Scrum - Time And Story Points

Let me start by saying that this won't be a time vs story points debate. In my book, all is good if you use one (not both). If you feel that one of these units of measure work for you and help you track progress accurately resulting in meeting deadlines, then, by all means, use it. But be consequent and use one, perfect it and master it. Don't chase two rabbits and increase your team's overhead.

That being said, let's move on to what is the subject of the article: estimation for fixed budget/time projects (FTB).

Fixed time or budget projects can benefit the most from Agile Scrum for one simple reason: it provides a reliable method to measure the speed at which a team delivers done work - if properly used. Aside from this big if, I will also add that fix time & budget projects won't work with Agile. Agile requires at least one variable to unfold and when all variables are turned to constraints, there's no room for agility.

And FTB means that you have one of the two most important constraints fixed, therefore carefully gauging resources is paramount. You really need to know both how well and how fast you can deliver. Agile's notion of velocity comes in handy here. The basic definition of velocity is: quantity of work done per unit of time.

In Agile Scrum, the unit of work is the abstract story point and the unit of time is the sprint. This is a pretty versatile way of measurement since it allows for all sorts of possible conversions. More importantly though, it allows for fast, versatile and reliable workflows. An idea comes -> translate it to user storie -> they go into backlog -> they get estimated -> they are prioritized. You already know now how many sprints it would take to finish them, right? Add measured units of work, divide by velocity and boom, number of sprints to complete the project. As this gets updated at most every day and at least every sprint, there's transparency in the process.

Now, when I say velocity here most Scrum Masters think about user stories. But this isn't necessarily so. Mike Cohn supports the idea of time estimation at sprint level. It's a perfectly good tool to use if you know that you team can use it to produce reliable results. But that's the caveat I'd like to point out: the very reason for story points' existence is that time estimation is unreliable. Whenever you ask someone for an absolute value for something in the future: it will be a lie. From meteorology to stock markets, all estimations and forecasts fall into ranges rather than fixed values because they work with systems that can't be controlled 100%. Same goes for programming.

Time estimations are false since inception and moreover they create mental deadlines in addition to those you already have: sprint review and the project's constraint. Since they are false and at the time they are given they aren't based on anything concrete, they provide a false sense of control that disappears the moment the time estimated has passed.

In fact, there's no fine-grain estimation strategy that could work, but the question is: why would someone need fine-grained estimation (and tracking)? The progress measure that Agile Scrum promotes is the delivery. You deliver functionality, burning items of work. Progress is measured by what is delivered and tracking is done by what's left. The speed at which you deliver constitutes the basis for forecasting the project's evolution. It is quite elegant and simple but at the same time reliable. You don't have to guess, only to measure.

But here comes the rub: the Hour as a unit of measure for work keeps coming back for one simple reason: clients get billed by the hour (man-hour). They pay by the hour so they want control by the hour. It's bookkeeping 101 - bills says hours, you want justification for hours. Bulk estimates tend to conceal inefficiency, but the question here is how does the client want to measure the efficiency? By justifying billed hours or by deliveries? In Scrum, something is produced every sprint. The Client should be encouraged to use this unit of measure in assessing whether the money is well-spent.

And then there's the matter of trust (or lack thereof): if the transparency offered by backlogs and daily updated burn-downs doesn't promote trust then how exactly would playing a guessing game help with that?