The Pomodoro updates
The personal backlogThe 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.
ConclusionsIt 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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)