If you ever worked with me you would know I’m not a big fan of estimates, mostly for the reasons better explained here, here and here, but there are still moments within a project where there are a bunch of stories written and teams need to have a guess on how much time will be needed

  • the project might be beginning and we need to know what is realistic or not
  • there might be go to market activities that need to be synchronised in advance
  • there might be a fixed deadline and we need to understand if there is any chance of making it or not

In cases like these, I’m still not a big fan of using planning poker or similar practices. First of all, it takes a _lot_ of time. Whoever has experienced a long session of estimation can probably remember people rolling their eyes as soon as we get to card number 54 (or around that…).

And handling the short attention span of tech people (which could probably be increased for the better) is not the only problem here. In every project there will be a lot of similar cards, and reestimating similar things over and over is probably not the most productive thing a software team could be doing, and also tests the patience of anyone involved.

Instead, what I’ve used in the past is a simple technique for group estimation (that I’m sure I saw somewhere before, so don’t credit it me for it) that will allow a group to get to some numbers with less time and effort.

1. Write all the stories you have in cards, and put them on top of a table.

2. Create 3 separate areas within the table, based on different timeframes. What I normally use is 1-5 days, 1-2 weeks and “too big”.

3. Ask the team to go over the stories and position in the categories they find appropriate. Let individual people move (and move again) cards however they want for a few minutes.

4. Let everyone go through the table and look at the cards, and observe the ones that are being moved between categories frequently.

5. Get the unstable cards and the ones in the “too big” category and discuss them within the team. Rewrite cards as appropriate.

6. Rinse and repeat if needed.

Is it precise? Probably not that much. Are any estimates precise? Definitely not. So far every time I’ve used we got a good level of results that were in the right timescale, which is probably the most you will get from software estimates anyway.

Regarding the fact that every story is not individually discussed within the team, a common argument in favour of detailes estimates, I believe there are better times to do that than when looking at all the cards with no context or experience working on them. Time to establish some story kick-offs maybe?


If you have ever been in an Agile project, or something that looks like it, you should have heard about the concept of spikes.

For those who haven’t, spikes are the agile response to reducing technical risk in a project. In case you are not sure how to build something or fear that some piece of functionality might take much more than expected, and you have to gain more confidence about it, it’s time to run a spike. Usually timeboxed, spikes are technical investigations with the objective of clarifying a certain aspect of the project.

In my current team, we are developing a few tools that are quite specific to our context and were not sure on how to solve a few issues, so we have been quite frequently playing spike cards.

This is all not new and I’m sure most of you have done that before. If you did the way I used to do, you would write a spike card, something as “investigate technology X for problem Y“, would spend 2 days doing it and would have a response for it in your head once you were finished.

In our current context, team members were rotating quite quickly, so we were worried that any knowledge we would get from spikes could have been lost if it was just…let’s say.. in our heads.

Not wanting jut to write the findings up, as we first thought about doing, we decided to tackle the problem with the golden hammer of agile development: tests!

So, instead of writing tests to decide how we should write our code, we started writing tests to state the assumptions we had about the things we were investigating, being able to verify them (or not) and have an executable documentation to show to other people.

For example, here is some code we wrote to investigate how ActiveRecord would work in different situations:

it 'should execute specific migration' do
  table_exists?("products", @db_name).should be_true
  table_exists?("items", @db_name).should be_false
it 'should execute migrations to a specific version' do
  ActiveRecord::Migrator.migrate(ActiveRecord::Migrator.migrations_paths, 02) { |migration| true }
  table_exists?("products", @db_name).should be_true
  table_exists?("items", @db_name).should be_true
  table_exists?("customers", @db_name).should be_false
it 'should not execute following migrations if one of them fails' do
    ActiveRecord::Migrator.migrate(ActiveRecord::Migrator.migrations_paths, nil) { |migration| true }
  rescue StandardError => e
      puts "Error: #{e.inspect}"
  table_exists?("invalid", @db_name).should be_true
  m =, ActiveRecord::Migrator.migrations_paths, nil)
  m.current_version.should == 3
  table_exists?("products", @db_name).should be_true
  table_exists?("items", @db_name).should be_true
  table_exists?("customers", @db_name).should be_true
  table_exists?("another_table", @db_name).should be_false

We have used this technique just a few times and I won’t guarantee it will always be the best option, but so far the result for us is having code that can be executed, demonstrated and easily extended by others, making it easier to transfer knowledge between our team.

For the Brazilian crowd (or anyone who wants to be part of it), between the 25th and 26th of April will take place in Porto Alegre (my home town : ) ), the 2009 Agile Weekend, which has my friend Daniel Wildt as part of the organizing team.

This will be hopefully the first of many Agile conferences happening in South Brazil, and will serve to boost even more Agile adoption in the region.


Needless to say, I really wanted to go, but London is not close enough to Brazil yet…

One of the good concepts I’ve found while reading Goldratt’s books was the Student Syndrome, which Wikipedia defines like this:

Phenomenon that many people will start to fully apply themselves to a task just at the last possible moment before a deadline. This leads to wasting any buffers built into individual task duration estimates.

During the recent discussions about estimations, which happened in many posts, Chris Leishman wrote about the 3 reasons (P’s) for estimation (which are extremely correct, in my opinion), and selected performance as one of them. As Chris wrote:

The throughput (velocity) of a team is determined by the amount of ‘work’ being done over a given time-period and is measured in terms of the estimate.

After reading this post, I realized that measuring only delivered story points in an iteration (one thing I always thought was right), might not be enough to enable the full capacity of a team.

Explaining, story points are used as de facto standard in agile projects because they provide the separation between time and effort. This way, when I estimate a story as a developer, I have no time commitment to implement that story, and therefore cannot be blamed if I take more/less time than expected (what is probable, since estimation is just an educated guess).

While this practice is good because protects the developer from bad managers, at the same time it provides a lot of room for the occurrence of the Student Syndrome, since nobody knows if the story was completed in the predicted time or not, and all the buffers that were mentally created by the developers during estimation get lost in non necessary activities, like gold plating, for example.

And what I have been noticing in projects, is that stories that get played at the beginning of an iteration generally receive a lot more attention (necessary or not) that the ones that are being done close to the iteration’s end, which proves the concept that more work could be done, if we had some intra iteration kind of measure.

Despite being against the addition of any unnecessary metric to a project, I’m starting to believe that something should be done in this case, like reestimate stories in hours, or measuring cycle time instead of story points, or any other kind of practice that brings awareness to the difference between our estimations and what is actually happening in a story level.