I have based this answer off one I originally gave on Quora, and have repurposed parts of it to make it more relevant to Developers.
For those of you that haven’t used the technique, at its core it’s a simple case of sitting down for 25 mins to focus on just one thing. Each of these 25 mins blocks is a known as a pomodoro. You have a 5 minute break to de-clutter, and then you go onto your next pomodoro.
The idea is that by setting yourself a manageable 25 min goal, you get into that state of flow you’re struggling with.
So how does this help us devs?
- It’s a good way of forcing yourself to read dry documentation, which can contain the answer you’re desperately trying scatter gun approaches to find.
- It’s a good way of avoiding context switching. 25 mins is a long time when you’re focused.
- Related to the above it’s my go to way for getting into a flow.
However did you know there’s more to the entire technique? You can use it for estimating too. You can break your tasks down into 25 min blocks before you start.
Using Pomodoros to estimate and plan your day
Here’s an example grabbed from the 2006 version of the guide – it’s stood the test of time well.
In this, the squares boxes are the original estimate. The crosses in each box represents completion of each pomodoro. The cross through the line indicates completion of the entire task.
- So Task 1 took exactly 2 pomodoros, and we estimated correctly.
- Task 2 came in under the estimate – we thought before we started it would take 3 pomodoros but we finished (crossed out the task) in 2.
- Task 3 is ongoing. We didn’t finish in the estimated 3 pomodoros.
- At the end of the 3rd pomodoro we re-estimated it will take another 2 (changing shape shows the boundary between estimates and re-estimates).
As it happens, we were overly pessimistic in our re-estimate. We finished in just 1 further pomodoro, hence the line is crossed out before all the pomodoros are ‘used up.
Putting it into practice
There’s lots to be gained from using it for planning your day and forecasting future work. In a different Quora answer I mentioned gathering empirical evidence to explain your bosses optimism back to them[2].. two weeks of proof can be gathered simply by:
- Break your day into 25 minute blocks, using your calendar to see which meetings and appointments will break your flow.
- Before you start, estimate how many pomodoros are available in your day (i.e 25 min blocks in your work day, minus lunch and meetings). Mark these blocks as empty squares.
- If you’re interrupted, mark the reason why, BUT this is for you. This is not for your boss to micromanage you or ‘try and help’ you with. (Unless your boss is genuinely helpful, in which case, go ahead)
- The point is you’ll try and improve interruptions both external and internal but the fact remains they exist, regardless of your improvements. And there will be different ones next week regardless of this week’s optimisation.
- The number you actually get to complete is for your boss. Consider this your ‘source of truth’.
I won’t go into the difference on internal and external interruptions since that can be found easily on many papers on the technique. The point is that it’s extremely useful for painting a realistic picture of your blocks of productive time.
And given that us developers give terrible estimates that forget meetings, documentation, fixing up/waiting for environments, interruptions etc we need all the help we can get.