Frustrating on time tracking

Question

Our agile sprint lasts three weeks. Say 40*3 = 120 hours. Our boss requires us must to log at least 8 hours every day. We use JIRA to record time. However my current story in the sprint estimated time is about 15 hours, of course it is not enough. Because I have to search online, discuss with team members and watch training videos etc. But even so I still can't log the whole time 120 hours. Be honestly, I am a quick problem solver, maybe I can use 40 hours to finish the project. After I finish my job, I can learn new technology related to the sprint project by myself.

The thing is if I logged more time on the agile project, the burn down chart would be ugly. If I logged less time to the project, my boss would be angry too, why do you spend much time on training rather than direct sprint work?

The terrible thing is that I heard that the performance would be related the time tracking.

So please advise me a right direction for time tracking.

Answer 1

Your company isn't following standard agile practices.

Ideally, you shouldn't be estimating in hours. You should consider estimating in Story Points, which is a measure of how complex the work is. You can then plan your Sprints based on these Story Points and the Velocity (number of completed Story Points) from a few of your most recent previous Sprints. If you happen to finish the work you started, you should be working on the next thing.

The next part is mandatory: the Development Team should be the one estimating, in whatever units you use (hours or Story Points or something else). If you are the one doing the work, you should be involved in estimating it. In fact, everyone who is required to complete the Story needs to be involved in estimating to make sure that the size is appropriate for the estimated amount of work.

As someone who works for a contractor, I do understand the need for tracking time. However, as I mentioned above, you typically estimate in Story Points rather than hours. Typically, a Story that is worth more Story Points will take longer to complete due to the various factors. However, there isn't a direct relationship between Story Points and hours. You should look at logging time against a project or activity, not necessarily a particular Story.

In order to fix these problems, you should first work on getting realistic estimates in place and using those estimates, along with historical data from previous Sprints, to plan future Sprints. The next step is to look at the overall process to make sure that the Development Team is able to commit to a reasonable amount of work for a Sprint and that, if the work is completed ahead of schedule, that additional work can be brought in. Finally, your Sprint Retrospectives should be used to talk about these problems and come up with methods to fix them.

Answer 2

While I agree with Thomas Owens answer, I think this needs a more strongly worded answer. The process you describe is completely missing some of the most important parts of agile management and these are the parts that managers should care the most about. (full disclosure: I'm a manager.)

In order to improve predictions about when work will be done, estimates should be done relative to other work that the team has done in the past. Then empirical data is used to predict how long the work will take. This can done using basic statistical methods and as there is more data, the picture of work throughput (averages, variance) become more clear. The managers should also then be able to detect trends as to whether throughput is increasing or decreasing in a statically significant way.

The other issue here is the use of hours. There are some big problems with using hours as a metric:

1. What's an hour? Is it an hour of 'flow' coding? Is an hour of looking debugging a head-slapping mistake an 'hour'? If you estimate 8 hours a day, when do you look at your email? What if you help co-worker for 30 minutes. Do you subtract that half-hour from your hours for the day? How do I know that one developer's idea of an hour is the same and another's?
2. Who cares about how many hours something takes anyway? What's the precision of the deadline? Surely it's not down to the hour. If someone is trying to calling development that close, they've already failed.
3. No developer knows how many hours (regardless of how you define it) it takes to get things done. Ever notice that when you are really crushing it, you look up and the day has passed? Humans minds suck at measuring time even when they are focused on trying to do that.

I argue that the smallest proper unit for predicting development is a day. Unless you are working in a cave (bunker, casino), everyone can agree on when a day has passed. There's this large bright orb that passes over our heads with amazing regularity. An arguments can be made for weeks depending on the situation but they are less uniform (e.g. vacations and holidays.)

I am not saying that estimates should be given in days (even though, it's a huge improvement over hours.) I'm saying days should be the unit of the predictions made by the manager. And to come full circle, when the manager (or scrum master) has the developers estimate in hours, they are usually delegating their job to the developers. And if all they do with that is check whether the developers hit that estimate, these estimates are worse than useless. They are actively disrupting the development process by occupying the developers with a BS game and likely lowering productivity by increasing stress levels.

Answer 3

This is a common issue regardless of whether it is 'proper agile' or not.

What you should do is record 8h total against the main task you worked on in a day regardless of how many hours you actually spent on it or other tasks.

Estimate in days and multiply by your required hours per day.

Round your estimates up to the nearest day. Usually there will be no need for padding as multiple small 1 day tasks will generate 'extra' time for the larger tasks.

This will result in:

1: pretty burn downs with nice constant gradient graphs.

2: happy project managers who can cost your time to the relevant project

3: happy programmers with simple timesheets.

4: slightly over estimated project length. you may have to bundle up small tasks

Answer 4

Our boss requires us must to log at least 8 hours every day.

This sounds pretty straightforward - if you spent the whole day working on a task, your manager wants you to log 8 hours against that task. If you spend 1/4rds of the day on task A and the rest on task B, then task A gets 2 hours, B 6 hours.

As others have pointed out this isn't good agile practice, but its what your manager has asked you to do so unless you are in a position to completely change your working practices you should either go with it, or look for another job.

There is however something that doesn't quite add up...

Our agile sprint lasts three weeks. Say 40*3 = 120 hours.
...
I am a quick problem solver, maybe I can use 40 hours to finish the project. After I finish my job, I can learn new technology related to the sprint project by myself.

If I have understood correctly then you are proposing to spend 120 - 40 hours a.k.a 10 days of a 15 working day sprint on "technology related to the sprint project by myself".

While its a good idea to take time for learning and self-improvement, 2/3rds of the sprint is somewhat excessive (to put it politely). If you have finished the sprint tasks allocated to you with 10 days to spare, then you be helping your teammates complete their tasks (and logging your time against those tasks).