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.
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.
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.
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.