Mostly results of experiments related to Agile

I've been developping software and platforms professionally since 1997 in tiny to big companies (I've spent 13 years at Thomson Reuters).
I discovered eXtreme Programming in 2001 and since then I've always worked using Agile Methodologies.

Personal Links

Verified Services

A new agile trend : No Estimates

You’ve probably already participated to projects which didn’t deliver on time. You’ve may have used a whole series of solutions to help improve predictions like “planning poker”, “velocity”, and so on. You may even have used Microsoft Project, Gantt Diagrams, Critical paths and so on. And it didn’t really get any better.

Then you are ready for No Estimates.

Vasco Duarte gives great presentations about the topic and here is one of them :

Let me try to summarize the method :

Starting with a significant project requiring several months of work,

you(a team) split this project into risk neutral units of work.

You prioritize the units of work. You evaluate every units of work, independently.

After 3 iterations, you measure how many units of work you are able to implement per iteration.

From this, you can predict how much time you need to implement all the units of work to end the project.

It’s probably just slightly different to what you were used to do. You were probably used to estimate the cost(story points) of every units of work(stories) and to calculate the number of points you are able to implement during an iteration(sprint). Then you would calculate how many iterations you would need to implement all the story points corresponding to all the units of work to finish the project.

The experience have showed that you can predict as accurately the end date of the project without estimating individual units of work as when you estimate the individual units of work.

So you don’t need to evaluate individual units of work. You can focus on what you are going to deliver and how you are going to progressively implement the project which has more value to customers than individual estimations of units of work.

Ok, but we can go further than that.

First, the reason why projects are delayed is not only that the estimations are not accurate but very often that the scope of the project changed, which is expected with Agile, no? So in that case not only you don’t need to evaluate independent stories but you don’t even need to estimate when the projects will end as this estimation will have to be reevaluated on a regular basis to cope with the probable changes in scope.

Another reason why projects are delayed is that you are not developing something that you have already done. Interesting projects are not copy/paste from previous projects and bring technical challenges that you never faced before. In that case, you just don’t know how much time you’ll need to overcome the biggest difficulties that you have anticipated. And you may even not have anticipated some of them. But anyway, having followed point 1 to 4 of the No Estimate method, at any point in time, you’ll have working software benefiting the customer.

How do I deliver new working features on a regular basis?

Nowadays, on many occasion, you don’t even have a customer who waits for you to deliver a project on a date. You have customers expecting there mobile phone apps, their websites, their Software as a Service, their Platform as a Service, their Infrastructure as a Service to provide new features on a regular basis to match the state of the art on the market. What is important here is “new features on regualr basis”. I think that it’s more important than any release date on a calendar but it means being able to deliver regularly. Regularly meaning more daily than weekly, monthly or even more than that.

In all these situations, you end with a No Estimation method using only 3 steps :

It doesn’t even have to be a significant project as you won’t collect statistics after 3 iterations.

So you don’t need to evaluate individual units of work. You don’t need to estimate when all this is going to end. You focus on delivering value to customers on a regular basis.

NB : The question around estimation is really a question of trust and habits. If you start in the state of mind that the team woking on the project is one of the best possible team, if the team delivers regularly working software which could be used by the customers, then the end date of the project cannot be made better by estimating individual stories. And as the team has delivered working software on a regular basis, if ever you cannot complete the project because you ran out of budget, you already have a working software with features beneficial to the customers.

Modern way to plan/release software

In modern IT world where more or less everything is web and the users/customers automatically get the latest version of a product deployed on a server, it’s possible to completely automate the release process and you should put you in a situation where you can deliver any update whenever you are ready. I’m preparing another post about “continous delivery” where I’ll describe some implementations allowing to deliver at any point in time.

Doing that, you simplify even further the step : You start iterating (implementing, releasing, receiving feedback from customers).

Implicitly, you had to group a set of units of work into an iteration and a release with some synchronization to do between the implementers of the different units of work . Now you don’t have to do that. Each unit of work has its own release which removes synchronization effort.

But, you may spend more time on : You(a team) split this project into risk neutral units of work.

Ideally, any unit of work should be something which could be implemented in less than a week so that you end being able to deliver one or more features every weeks. That’s where it’s difficult : being able to define the minimum viable feature to deliver to a customer.

Prioritizing the units of work is an art which is a subject in itself. Vasco Duarte has posted some proposals on how to prioritize work on his blog and I have at least one other proposal that I’d like to post later on.

So you don’t need to evaluate individual units of work. You don’t need to estimate when all this is going to end. You don’t spend your time synchonizing teams or team members. You focus on delivering value to customers on a regular basis.