[bendixso]

I do. I try to focus on improving my estimates. I find that some things work better when lumped into a general category like "Code Review" while you can be more specific with other things, for example a particular feature or user story.

You have to ask yourself, what value would you get from estimating that a code review will take 10, 20 minutes? Is that kind of information particularly useful for forecasting? I would guess it isn't because it seems too granular. Nobody I know sits down and plans a series or 10 or 20 minute code review sessions. They usually plan out bigger blocks of work.

I use a tool called Track - Simple Time Tracking and Invoicing (https://itunes.apple.com/us/app/track-simple-time-tracking/i...)

Full disclosure, I built Track and I own the company that sells it.

I built Track because I wanted a cleanly designed time tracking tool that syncs my data between devices and doesn't make me sign up for an account. It's iOS-only. It works on the iPhone and iPad.

So yeah, I use the tool that I built. I use it every day while I'm working on my client projects.

[agateau]

The thing is, we often have tasks estimated to last 2 or 3 hours. 10 or 20 minutes of review starts to be a significant duration in this case.

[bendixso]

Yeah, so in that case I think it would make sense to tie each code review session to the feature/story you are reviewing. Maybe that's what you were already doing. I'm not sure.

[agateau]

Yes, we consider a task to be done when code has been reviewed and merged, so our estimates include review time.