Using the Pomodoro Technique, developed by Francesco Cirillo, you work in focused sprints throughout the day. Matthias Günther delivers Pomodoro wisdom in short sprints on this series.

If you have followed my article series to this point you should know the rudiments of how to use the Pomodoro Technique to get control of your time. You know what Pomodoros are, how to run them, and how to defend yourself from interruptions. In this installment you will learn how you can better estimate your time for doing Pomodoros.

Is Estimation Evil?

I have to do it every sprint at work and nearly every time it is difficult for everyone in the team: Estimation.

If you are the Product Manager, you need estimates from the developer about features in order to prioritize them. You will use this information to determine how much effort it takes to build the feature and how much business value will be generated for the customer. This is part of the cost-benefit analysis. You will use this information to create a release plan of your backlog. For example, you want your marketing people to advertise the new feature to the users just in time and communicate it when it’s out and not the other way round. We all know that just-in-time is expected but difficult to achieve. The only constant thing in software development is change, and so we know that the requirements will change, and with them your plans.

Knowing all the requirements of a feature is almost impossible. There will always be uncertain variables:

• some of your teammates get the flu,

• the Product Manager is stuck for the whole week in meetings and isn’t available for questions,

• developers have problems with the infrastructure because the system team is doing some important migrating job,

• or you are fighting very nasty bad bugs, or you detect during the implementation that the design needs a whole refactoring, or...

• I’m sure can think more of these variables on your own.

All developers know about and expect these kinds of problems. But we tend to underestimate the time we need to solve the problems and we almost forget the unknown obstacle which will appear in some way. As a developer you have to chose a strategy to solve the problem, build the thing, and show it to your customer, and the sooner the better. Getting early feedback gives you a chance to adapt your feature to changes in the requirements instead of building in the wrong direction. This will save you time and money.

You need a plan for doing things but you know that your plan will not work in the way you want. You’ll have to adapt it in small steps. You can learn more about this topic in Ron Jeffries’ article, “Why Estimation Is Evil.” Let’s see what the Pomodoro Technique has to offer.

Make Estimations in Pomodoros

Remember the Activity Inventory Sheet? Right, it’s the piece of paper that is the gathering of all the things you want to do today. There is a special column in the sheet where you can draw boxes. Each box stands for a Pomodoro. There you have your estimation guessing area for each task. When one Pomodoro is over you make a cross in the next box. Each crossed box stands for one Pomodoro you’ve spend on the task.

Your first estimation.

The first image shows the task “Ruby Midwest talk.” It has four boxes. That means that I think that I need four Pomodoros to prepare the talk. Since I haven’t started any Pomodoros for this task, the boxes are empty.

You may ask what the perfect size for a task should be? In my eyes something between 1–4 Pomodoros is a perfect fit. If you think a task takes more then 4 Pomodoros it is actually too big and you should break it down. Splitting up big problems is like climbing mountains—taking small steps saves you from falling down and you will have enough time to think over your route, and you will have more time to take some pictures during your trip. The smaller the problem is the better you are able to estimate.

Determine Your Available Pomodoros for a Day

Before writing down your estimations for the each task you first need to determine how many Pomodoros you have today. A bad day may only consists of four Pomodoros for concentrated working.

On nice days, where you have the feeling that you are actually working, you have between 8–13 Pomodoros. These are times where you are feeling the team spirit, leaving your comfort zone, reaching for the stars, and making the impossible deadline possible. You are happy to do your beloved programming job. Yes, you’re feeling smart.

Have your “available-Pomodoro-number-per-day” in mind before you create a list with tasks for the day. Think of these tasks as a commitment (or “promise” to say it in with the words of Uncle Bob) for day. The nice side effect of this strategy is that you are limiting yourself about the things you can really finish that day. Kanban describes this way of working as “Stop Starting, Start Finishing.”

Tracking Your Estimation Progress

At the end of the day.

At the end of the day you should have have a list like the one in the next image. As you can see there are tasks where not all boxes are crossed. These are tasks that took less time that you thought in the beginning (overestimation). If there are more crosses then boxes beside a task you have take more time that you estimated for it (underestimation).

At work I track the time I need to solve a problem, but instead of thinking in a classical time estimating mode, I’m using Pomodoros as my metric. At the beginning I may have had 4 or more at some task because I was working in hostile environment without any tests and very old legacy code. It was more than 5 year old code and all comments were wrong. If you are not experienced with this kind of work you can triplicate the time you think you need at the beginning.

Picture of the Record Sheet.

You can track your estimates on the Record Sheet. The difference between estimated and real results shows you how well you estimated your task. If the differences for tasks are between -2 to +2 you’re pretty good at estimating.

I’m not using the Record Sheet yet. I’m only using the Activity Inventory Sheet to track the estimations of my Pomodoros. Out of historical data I can say that I’m a much better estimator than I was before I was using the Technique. The most important thing is to recognize when and why you need so long for a task. Was it due to lack of skill, due to some stupid decision, because you didn’t talk to anyone about the way you want to solve the problem, or because you were solving the wrong problem? We all make mistakes, and mistakes are the best fertile ground to build up your developer skills.

Don’t give up if you have a huge gap between the estimated and needed Pomodoros. This will work better if you keep practicing it.

Conclusion

Estimation is one of the things programmers hate. We all have trouble predicting the time we need for a story or single task. Only after running a marathon do you know how long it took. It is the same if you are working with your team on a long-term project. Only when you are finished with it do you know where the bottlenecks were. Apparently every large project in IT is different and difficult to estimate, and there will always be external dependencies or unforeseen problems that will destroy you plan. Edmund Burke summarizes this perfectly with “You can never plan the future by the past.”

But by using the Pomodoro metric to track your commitment, you become better at estimating and at keeping your promises to your users, Product Owner, Team, and yourself.

Matthias is an Open Sourcer by heart, loves giving presentations about Vim, and writes a book about Padrino. When Günther is not working as a developer at MyHammer, he spends his free time visiting hacking events, painting small figures, running for his health, organizing Ruby conferences like eurucamp 2013, and experimenting with making delicious cakes. He lives in Berlin and is blogging under wikimatze.de You can see Matthias speaking at Ruby Midwest 2013 about using the Pomodoro Technique for Open Source work.

Send the author your feedback or discuss the article in the magazine forum.