I've used "strict" Pomodoro technique at times. At its simplest, the structured rhythm of timeboxing and breaks is a useful tool for keeping focused on work th

I've used "strict" Pomodoro technique at times. At its simplest, the structured rhythm of timeboxing and breaks is a useful tool for keeping focused on work that benefits from high focus, e.g. plowing through some "heavy implementation" work, coding, debugging, grinding away in CAD, etc. On the other hand, I've found that it can be a detriment to other kinds of work, more creative or high-level design oriented work. Some days, it's just better to be a bit more relaxed and free-form, even get out and take a walk and let ideas percolate. I've always found the estimation bit to be tricky, because its viability depends hugely on 1) the kind of work you're doing and 2) whether you're running an ongoing planning deficit or not. To point 1, the less well-defined your work is, the harder pom-level estimation is. For example, consider a task that boils down to "learn how to apply, new, complex set of APIs to solve problem X", but might just be written as "implement wireflow 2a". At some point, despite planning effort, you end up with tasks that are indivisible atoms with high variability. I don't necessarily feel it's worth putting a huge amount of time learning to precisely estimate those, if it's even possible. (I'd love to hear counter-examples from folks, tho.) My personal approach is really to try to bubble up overall variability/uncertainty to a higher-level than counting-the-poms, then mostly use poms to maintain focus/velocity. As to point 2, part of the Pomodoro Technique is supposed to be doing a planning pom at the start of the day, and that's really the minimum. Sometimes that's not sufficient (e.g. you have higher-level planning/workflow problems), or sometimes your planning skills just need work. If you're at least doing your planning pom, that gives you time to reflect upon and begin to address these higher level issues.