Why Does it Always Take Longer Than I Thought

How much work can we fit into an iteration. Well that's an easy question to answer. You know how many people you have, can size the work, a bit of math and you have your answer... simple!

Well unfortunately its not anywhere near that easy and if you think it is, probably explains why you have to rush, get surprised why things are taking so long and if a manager, wondering if you have the right team for the job.

The truth is that everything takes longer than it should. Well actually it takes as long as its supposed to.

I remember a top manager saying "Our quality is good but the work ALWAYS takes twice as long compared to the estimate and that is not good enough". Well I'm sorry to say that if it ALWAYS takes twice as long its the estimation that is the problem as it should be twice as big (to half the time taken you need to improve processes not use un-realistic time scales).

NO ONE ever works on a task all the time:

• There will always be problems that no one thought of
• If you are a team you will be helping each other
• People will interrupt you for information or you may need to go see them
• We all need to get away from the computer from time to time

An approach that can be used to estimates which are a bit more like reality is Velocity Estimation.

Creating Focus At Time Box Planning Meetings

Focus is all important for meeting long term goals. When using a waterfall approach to software development the ultimate goal is usually huge and too far away to comprehend.

Using agile approaches help as we are focussing on the next release and some delivery 18 months away. Use your Time Box Planning meeting to identify the goals for the iteration. Make them achievable and pack a few extras into the iteration.

Make sure they are something functional, something where you can see the results, demonstrate to any stakeholders so they can give feedback on what they like and don't like.

Don't try to push the team by having too many goals in the Time Box (push then at the stand ups). We want to get to a position that people can trust that goals are going to be achieved so they can feel confident that progress is being made. The extras will be seen as tasty bonus treats.

Reduce Constant Interruptions With Time Box Planning Meetings

One of the problems with software development can be the constant interruptions and moving requirements from the customer. This problem can arise because the customer, internal or external, can feel they only have one chance to get things right. But with agile development we can always change and improve the software.

Make sure the stakeholders understand that for each iteration they will be invited to a planning meeting where we can all assess the development so far and identify the next most important issues that need to be addressed. Make it blatant that no decision is final, all things can be changes and nothing is wrong.

Once you can get this understood then stakeholders and developers are more likely to look at the bigger picture rather than get fixated on some trivial issue that may only be important to themselves.

The part of the planning meeting attended by the important stakeholders should be short, half an hour is ideal. You will find the most important things are discussed in that half hour and any longer is generally used to discuss trivial issues and unknowns (let the unknowns mature for a while you will know what to do in a later iteration).