Agile Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

The Pomodoro updates

  • submit to reddit
It's been a while since I presented my programmer experience with the Pomodoro technique. Here are my updates and the recap of the goals we should follow when seriously adopting this tool.

The personal backlog

The classic TODO list is still a fundamental tool for time management. However, calling it a personal backlog shines light on some similarities with product and sprint backlogs:
  • it contains one item for each task to accomplish.
  • When new activities come up, they are included at the end of the backlog without being picked up immediately.
  • At the end of a Pomodoro (sprint), these activities can be reprioritized. When they are very small, they can be picked up even in the original Pomodoro if the previous activity finished.
  • The backlog contains only pointers, just like user stories are represented as cards that act as reminders of a discussion to have with the customer. There are other places where to store details about TODOs (usually the code itself, or an incomplete test).
  • It's a low cost, low overhead tool: you can delete or move activities around without hassles.

Pomodoro in a team

Working with the Pomodoro technique inside a team isn't as easy as adopting it as a freelancer.

For example, breaks have to be adapted to the "break frequency" of the people you are currently working with. Long breaks usually stay real breaks of 10-15 minutes, but short breaks may become just short interruptions to keep cadence and assessing how much of the work is completed. This is especially true when working with other people who are not users of the technique: there is a balance between imposing breaks and self-assessment and other priorities like getting the selected story in production.

The amounf of interruptions that can be tolerated is also set to the team's preferences; in the last team I worked with, a single question or phone call can be handled immediately, especially depending on what is the issue.
In fact, any real-time scheduling algorithm (and even every application) sustaining a non-trivial load contains a trade-off between throughput and latency:

  • throughput is the amount of tasks that are finished in a unit of time.
  • Latency is the time between the creation of a task and the end of its execution.

The Pomodoro technique is naturally effective in a context where there is a low penalty on latency (very few things cannot wait for 12 minutes) and a focus on throughput as the measure of productivity. Usually the technique is adopted after the team is stressed with many interruptions that supposedly need to be addressed immediately (the "everything is urgent" mindset).

However, especially when teams start to work on the whole pipeline (consisting both of development and operations), there are particular tasks that require a low latency. For example, if there is a problem on your billing page, you may be losing money every minute; fixing that problem is a priority that should trump your running Pomodoros no matter what (it should even trump the sustainable pace and the lunch break, in my opinion.)

I suspect this is true for a small percentage of tasks everywhere: imagine a broken build and how every running Pomodoro in the office should stop to allow the team members to fix it. So reason about your context (a team managing development, production servers, or both?) and work on each task according to its real business priority: throughput or latency.

A recap of objectives

Here are the 5 original objectives of the Pomodoro technique, along with a comment or an example for each of them.
1. Finding out how much effort an activity requires

I think you must iterate on similar activities to have a significant sample, just like you measure velocity over multiple iterations of several weeks.

2. Cut down interruptions

The requirement for many interruptions is a sign of a chatty process: if you can group team members in a more cohesive way the communication overhead can be lowered (not to say that it isn't necessary). But keep an eye on latency and throughput requirements.

3. Estimate the effort for an activity

Well, if you can measure previous instances of a task, you can start predicting how long it will take; and even if it's the first time you perform it, you can adjust it via feedback between the first and second execution. The time in Pomodori is often a good measure when the technique is followed because there are fewer spurious factors influencing the result (for example, the number of phone calls to answer during each execution). It's closer to Scrum's "ideal days" concept.

4. Increase efficiency

Time measurements are always prone to efficiency (not effectiveness) optimization. What happens if we try to test-first these new integrations? Do we gain time or lose it due to the sheer number of tests to write?

It's also a small timebox that can be used for experimenting new tools or practices in spikes of a limited length, bounding the amount of damage they can do if they do not work correctly.

For example, you could say: Let's try using MongoDB instead of MySQL for storing these new objects; if we can do it in less than 4 Pomodoros, we will stick to that. Otherwise we revert to MySQL as the default, which we know how to work with. The worst that can happen is that we totally waste 4 Pomodoros, but not a whole day for integration problems.

5. Scheduling activities

Scheduling tasks in a Pomodoro-based agenda is easy to do alone, but more difficult inside a team where everyone may be tracking his time differently.

I've seen fixed points being established, like a standard time for standup meetings; this practice helps in decoupling members of the team (or pairs) from each other, and let them go along with their Pomodoros for the rest of the morning or even of the day.


It only takes a sheet of paper and a timer (or a smartphone/desktop application that acts as such) to experiment with the Pomodoro technique; this low barrier of entry is beneficial for adoption but sometimes results in a colleague copying the practice without establishing his own objectives. For this reason, if we try to think about a few of the 5 objectives at each break, we can improve our experience with the technique and make sense of all those timers ringing.
Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mario Fusco replied on Mon, 2012/10/01 - 11:26am

Questiion for the user of the Pomodoro technique: have you ever been in "the flow". And if so doesn't drive you mad that a timer comes to interrupt it after 25 minutes while it could continue for hours? Personally "the flow" condition is the most productive state I can reach and I beleieve that the Pomodoro prevents to get you in it or at least kicks you off it after a few minutues. This is probably the main reason why I am strongly againts this technique.

Giorgio Sironi replied on Mon, 2012/10/01 - 11:59am in response to: Mario Fusco

I have addressed this question multiple times; the problem is that the person experiencing flow by definition loses track of time while being neck-deep into the task. So it's easy to feel very productive, but spending 3 hours in refactoring endlessly or covering very rare error cases. The timer ringing helps me in at least two ways:


  • reminds me that 25' are passed and lets me choose between add time or cut scope
  • lets higher priority tasks kick in, but only at predefined moments and not at random time.
So flow-like experiences can be maintained for no more than 25', but also for at least 25'.


Mario Fusco replied on Mon, 2012/10/01 - 12:12pm in response to: Giorgio Sironi

I completely disagree with this. You're not in the flow during a Pomodoro. You are just doing your job without interruption but not in the flow. What I call "the flow" is a state of sublime concentration that allows to do in 3 hours the same amount of work that you normally do in 3 days. It is definitively not something you can switch on and off at your needs, with or without the help of a timer. People who don't recognize the difference between a Pomodoro and "the flow" never experienced the second one and I believe they never did exactly because the Pomodoro prevents you to reach that state.

Uberto Barbini replied on Mon, 2012/10/01 - 4:31pm in response to: Mario Fusco

My take is that if you are in the zone "you ain't need no pomodoros" :)

Still we all often have to do tedious tasks, or maybe some days we just couldn't concentrate. Well at least it happens to me. In that cases, preparing a list of the tasks of the day (or the morning) with the estimates in pomodoros and then going through them without distractions, it really helps. At least it helps me.

Also 25 minutes are really quite the right compromise between concentration and stress.

 So in conclusion I found it useful when I'm stressed or not productive days.

Vassil Dichev replied on Tue, 2012/10/02 - 12:54am

Hey Mario,

If you're in the flow, then you're not really doing work ;-)

Seriously, I think at least Staffan Nöteberg (the author of Pomodoro Technique Illustrated) has been honest that the Pomodoro technique might not suit everyone and will not be appropriate in every type of work. It does shine when you have to do routine (read: boring) or difficult (read: exhausting) types of work. If you don't have any activities like this in your day job, you're one lucky guy!

What I find that the Pomodoro technique helps with the most, is the following:

  • doing one thing at a time (avoid multitasking)
  • breaking down tasks into manageable chunks
  • keep a sustainable pace
  • avoid wasting effort in unproductive tasks

When you're in the flow, you naturally avoid multitasking, and you might have an easier time working on a manageable chunk of work. But you still might benefit from the other points. For instance, you might do a 3 days' worth of work in 3 hours, but then you might feel exhausted and unproductive for the next day or two. Taking a break regularly helps you to not burn out- something which is very common in our industry.

Also, how many times have you found that you've done a task to perfection, but this task has been unnecessary? It's no use doing things right, if you're not doing the right things. Doing a break once in a while helps you regroup and evaluate your progress. Is this a dead end? Does this seem like it will take much longer than anticipated? I, for one, have found not on one occasion that my effort to "just write my own X" or "just refactor this stuff" takes so long that it could delay the project significantly.

Finally, I think you're overestimating the ability of a 3-5 minute break to interrupt flow. For example, some folks think that staying hydrated helps keep the brain in top shape. This might or might not be true, but I like to make myself some tea once in a while (let's say once an hour). Making tea takes me about 5 minutes. Other folks swear that without coffee they're not able to function at all- a common pattern among programmers. Making coffee takes a couple of minutes. Noone complains it's breaking their flow. With all of this drinking, you have to go visit the men's/ladies' room pretty often. This takes me about 3 minutes. I've never seen someone complain that going to the toilet has broken their flow. Well, my 4-year-old son still finds it hard to stop playing just to go to the toilet, since he believes he would miss something terribly important, but I'd like to think we know better than that :)

In conclusion, I'd be hard pressed to remember a simpler technique than Pomodoro, which also makes it very flexible. It's basically another name for time boxing. I've done time boxing before the Pomodoro technique and found it has helped me immensely stop procrastinating and start on huge blobs of work by breaking them down. If you haven't tried the Pomodoro technique for something like 2 weeks, you might find that your fears don't hold water in practice. If you have tried it and it really doesn't work- don't sweat it. It doesn't mean it won't benefit you when you're doing some boring task you've been putting off. Try it when you're doing your time recording or your taxes- you would really surprise me if you say you get in the flow doing these :)

Mario Fusco replied on Tue, 2012/10/02 - 2:57am in response to: Vassil Dichev

Thanks for your reply Vassil,

What you wrote makes sense. Probably the truth is that the Pomodoro technique doesn't fit everybody and I am just one of them. When I tried it I remember I got upset because it often happened that I was "almost" done with what I was doing but the ring of the timer "forced" me to suspend it and restart after the pause just to complete the remaining part of my task in only 3 or 4 minutes. Other times I found myself writing bad code just because I was in an artificial hurry to win my race against the timer. Even worse the biggest part of the other colleagues in my office experimenting the Pomodoro with me used it just as a shield. A way to implicitly say: "hey, don't dare to interrupt or bother me while I am doing my Pomodoro". Two of them arrived to point of refusing to answer to a customer call because they were in the middle of their Pomodoro. After this awful experience I declared the Pomodoro experiment failed and forbade it in my team.

Actually there's a more general (but very related) question I ask myself since a while: "why do so many software developers feel the need to play with toys and trasform their day by day work in a funny game in order to get some job done?". If I go to my cousin job place, he's a civil engineer, I don't see any Pomodoro on their desks neither I've never heard him speaking with his colleagues of how the 2 weeks sprint is progressing. If I'd visit my sister's office, a lawyer, and I'd ask why they don't have a wall completely covered with stickes or at what time they do the daily stand up meeting she would just laugh at me.

In a word, in which part is our job so different from the others to require this kind of "special techniques"?


Vassil Dichev replied on Tue, 2012/10/02 - 3:58am in response to: Mario Fusco

I get while you're so upset, but IMHO you and your team were misunderstanding how strictly the Pomodoro should be applied. If you really have only a little to finish the task, you don't need to stop immediately, but take another 2-3 minutes to wrap up. Also, if you manage to finish the task in the first five minutes of a Pomodoro, it's OK to start another task. If you can't finish in 5 minutes, but it takes too long to wait till the end of the Pomodoro, I don't see anything wrong with cancelling the Pomodoro.

I find that when I get used to this rhythm, I plan my tasks better and manage to finish at least some of them around the 25-minute limit. If I need to continue, the line where the cursor is in my editor is usually enough to remind me where I left off. If not, people report that writing a word or two down before the break helps them restore the context. I don't need to rush things, because I know I can always start another Pomodoro. This is not a race, and noone is tracking how many Pomodoros it has taken me- it's for my own benefit. You don't need to show your Pomodoro statistics to others, and indeed I don't think it's beneficial to add peer pressure to the one you apply yourself.

The goal of the Pomodoro Technique as I understand it is certainly not to aim to finish the Pomodoro at all costs. It's a gentle indicator for how efficient you are. It's OK to void the Pomodoro. There could certainly be more important tasks than the one you're currently doing in your Pomodoro- the goal is to be aware of it and decide whether to void the Pomodoro, and not switch reflexively out of habit. Besides, a customer calling would interrupt your flow whether you're using the Pomodoro technique or not. I wouldn't use the Pomodoro technique at all if my job is to talk to customers most of the time. If you want to get in the flow, you would pick a block of time when you're not likely to be interrupted anyway, wouldn't you? Many people do this either before or after standard working hours. You might as well inform the customer that there are times, when you might not be available for calls, and we do this all the time- we don't take calls while we're in a meeting and we shouldn't take calls when we're home with our family.

I have seen many references to time boxing and work chunking. University teachers have told us students that we should study smart, and not hard, and this included taking regular breaks. I've read books on motivation, which stressed the importance of eliminating interruptions, dividing work into manageable chunks, knowing when to stop and rewarding yourself for small achievements- things that the Pomodoro technique is about. I don't know whether it's applicable to all or even many professions. I know in our profession it's harder than most to keep track in your head what you have accomplished and what is still left to do- so we use tools for that. You must know first-hand how hard it is to estimate tasks in software engineering, especially as the size of the task grows.

Even before hearing about the Pomodoro Technique, I knew time boxing can be useful. I knew task chunking can be useful. I knew taking breaks regularly can be beneficial. Many people argue that multitasking leads to a drop in productivity. These techniques might not be applicable in all contexts, but I think they're used in many more professions than we give them credit for- otherwise there wouldn't be so many books on the subject. You might not call this Pomodoro- I don't care really- but it does bring together many of these simple concepts.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.