3

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.

Improve this question
4
  • 5
    "Hours". If your company is doing Agile correctly, you are not tracking "hours". Who is making these estimates? In any case, it is not clear to me what exactly what you are asking, because I don't know what you mean by "But even so I still can't log the whole time 120 hours." – Gort the Robot Apr 4 '16 at 15:52
  • @StevenBurnap, English is not my mother language. So sorry for unclear. I meant that I am supposed to log the entire 120 or a close number on direct sprint job. It will appear my contribution on the agile projects is big I think. The project manager and the dev team estimated the time and sub-tasks. – Love Apr 4 '16 at 15:58
  • 14
    This has nothing to do with agile and everything to do with shitty management. – Euphoric Apr 4 '16 at 16:15
  • I guess the part I am not understanding is that do you mean you are completing tasks in less than the time required, or taking more than the time required. (Though in either case, it's clear that your management does not understand agile, because in Agile, you should never be asked to work on something with contributing to estimates. – Gort the Robot Apr 4 '16 at 16:39
7

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.

Improve this answer
5
  • 5
    A key point is that in Agile it is all about team performance, not individual performance. – Gort the Robot Apr 4 '16 at 16:43
  • Do Agile story points eventually translate into actual hours via some formula or other mechanism? I'm not sure how moving from vague estimates in real hours to vaguer estimates in fictional story points improves matters. – Robert Harvey Apr 4 '16 at 18:24
  • 3
    @RobertHarvey No, there's no direct and consistent translation from Story Points into Actual Hours. Personally, I don't believe in "Story Points or Nothing" - estimating in hours is totally OK, as long as it includes all necessary tasks and the team comes up with the estimate. The advantage to Story Points is that it can't be tied to hours, so it helps management make the transition to a more agile thinking by eliminating old ways. – Thomas Owens♦ Apr 4 '16 at 18:26
  • @ThomasOwens, thanks. If I find I need to add something to the story. Can I create a new sub-task during the middle of the sprint? – Love Apr 4 '16 at 19:22
  • 2
    @Love: Yes, you can add new sub-tasks to a story mid-sprint. You should mention in the daily standup that you found something that was overlooked in the planning (which will happen) and that such-and-such task is also needed to complete the work. – Bart van Ingen Schenau Apr 5 '16 at 7:44
8

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.

Improve this answer
2
  • A follow up question. My manager want to measure employee's performance based on the hours metric. Say we have three categories, direct sprint job hours, development meetings and training hours. So during the latest 20 sprints, the more direct sprint job hours(ex 80%) involved then the best performance elevation. Is it right? – Love Apr 4 '16 at 17:42
  • 4
    I can't guess at what your manager is doing with this. I can only tell you I disagree with it based on what you have described. – JimmyJames Apr 4 '16 at 17:47
1

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

Improve this answer
4
  • 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. In some environments, this is not only unethical, but illegal. For example, in government contracts. Failure to record accurate actual hours can lead to punishment for both the individual and the company. If you are being asked to track time for a company, you should be properly recording time. – Thomas Owens♦ Apr 4 '16 at 17:04
  • "Our boss requires us must to log at least 8 hours every day." – Ewan Apr 4 '16 at 22:28
  • English may not be the native language of the author. That phase could mean that the boss is demanding that the employees work 8 hours a day on the project, or simply work for 8 hours a day or more. If the boss is requiring logging hours not worked, then that's a problem, but I don't see that suggested anywhere – Thomas Owens♦ Apr 4 '16 at 23:12
  • Except he literaly says it. Also as I say in my answer, its very common that you are required to log your full days hours against tasks even if you had meetings, training etc because your time is billed forward – Ewan Apr 5 '16 at 5:37
0

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.