The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I currently work M-F 8-5 with 1hr lunch breaks. Which leaves me with 40 hours of "work" a week. I am trying to come up with an ideal amount to use when setting up my sprint backlog. I can't use 40 because I just don't work a hard 40 hours in a week, meetings happen, the occasional extended lunch, helping other coworkers with their projects or questions, etc.

I am currently thinking that 34 hours seems like a reasonable number to say that I will actively be working on a project for a week.

I was wondering what other peoples thoughts are on this or if there is a more set number that the industry uses?



migration rejected from Jan 16 '14 at 21:27

This question came from our site for professional programmers interested in conceptual questions about software development. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by Chad, CMW, CincinnatiProgrammer, Jim G., jcmeloni Jan 16 '14 at 21:27

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

My boss requires everyone in the office to log their activities every day. When we asked how we should log the activity for logging the activity, the response was, "Oh, it should be instantaneous!" The sad truth is that 30 minutes of everyday is falsified because we all have to pretend it doesn't take any time to do. – Neil Jan 16 '14 at 14:01
@Kieveli - even if you are working 40 hours, some of that work is meetings and other business overhead. – Michael Kohne Jan 16 '14 at 14:01
Since you mention a sprint backlog, are you talking about scrum and intend to get a basis for your estimates with this number of hours? – CMW Jan 16 '14 at 14:15
Isn't that generally a team (or sometimes management) decision? Do folks on your team decide how much time is available to the Sprint individually all on their own? – Joe Strazzere Jan 16 '14 at 14:18
This question appears to be off-topic because it is about scrum not navigating the workplace. – Chad Jan 16 '14 at 17:26

This is a good question.

I would say that, for certain, 100% productivity is impossible. In college, they actually taught us that as Graphic Designers, our productive time is only about 60%.

If you provide an invaluable creative, or technical service, does it make sense to work under the same terms as someone who bags groceries? If you think so, please come work for me, and I will pay you very little money to pour out amazing technology and design at an unfair rate, so that I can profit readily.

Often, my productivity time (which I count as actually being in the zone, totally focused, working on a product) is no more than 15%.

There are two kinds of workers, I've found, shotgun workers and sniper workers.

Shotgun workers are productivity people. They get a problem to solve, and immediately they whip out their trusty shotgun and start blasting away at it. They blast and blast and blast away at it, until it's gone. It's of little consequence how much energy it took to actually do. Such workers are usually very good at looking busy and even better at wasting their own time.

Sniper workers prefer to take as few shots as possible. Given the same problem, a sniper worker would probably go to a nice, quiet knoll, overlooking the whole scenario. Then he (or she) will simply lay there, waiting, and considering. They will determine their targets weak point, and then swiftly and cleanly solve the problem. Often, it looks like these guys aren't working at all. But they are!

The big difference is that the shotgun approach doesn't tend to scale well! Once projects get to a certain degree of complexity, the shotgun approach stops working, as it takes a huge amounts of shots to make it work. Sniper workers, however, scale all the way up, and are ideal for solving complex problems.

In conclusion, having lower productive time is good because it scales much better than high productive time. The less of your time you spend actually "doing", while still getting comparable results, makes you more of a sniper-style worker.

This is a good TWP answer... though it does not answer the programming part of the question. Since its on TWP +1. – Chad Jan 16 '14 at 17:31

If you are concerned about the exact number of hours you will work each sprint when setting up the backlog of an agile methodology, then you are doing agile wrong.

Agile isn't supposed to be about planning your week down to the hour so that you can predict how much you accomplish. It is about learning by experience how much you can do in a week.

It works like this:

  • Start with a rough estimate of how many hours you work in a week. The eact number doesn't matter, and there is certainly no need to ask a question like this to determine it.
  • When you accept a task into a sprint, estimate the hours to completion and accept about as many hours work as you think you have.
  • At the end of the sprint, look at how many hours of work you accomplished (i.e. not the number of hours work you actually put in, but the sum of the estimated hours of the tasks you completed). If it was less than you accepted, accept less work next sprint. If it was more, accept more.
  • Eventually you will get to know really well how much work you can complete in a sprint. It doesn't matter if the hours you estimate correspond with the hours you actually work, as long as you know how much work your team can complete.
-1 I have to disagree. If you're doing agile, you count abstract story points, not hours. Although JMarsch's remark about using hours as a secondary measure makes sense. – Jan Doggen Jan 16 '14 at 15:26
Many Agile methodologies do both. Often story points is used for initial task sizing, and then a more detailed estimate is made once the story is accepted. In any case, the answer would remain the same - you don't need to know exactly how many hours you work in a week to do agile. – DJClayworth Jan 16 '14 at 15:42
This is a good answer at programmers SE but not The workplace SE... I am confused about what to do... – Chad Jan 16 '14 at 17:28

The rule of thumb for time estimating is six hours of direct work for every 8 hours of total work. This allows time for company meetings, jury duty, vacation, unavoidable delay (like fxing your computer when it dies), indirect work like filling in timesheets and wading through emails, etc.

Six hours is the rule that my überboss uses as well. – Seth Gordon Jan 16 '14 at 15:33
Things like jury duty and vacation should be knowable at the start of a week/sprint. They shouldn't be averaged over a long period, unless you are doing detailed planning over a long period of time. but the OP is using Agile, so they shouldn't be doing that. – DJClayworth Jan 16 '14 at 15:44
even then you have unexpected time off for sickness and family emrgencies, so allowing some time for this sort of thing will help. Perhaps not as much as I need to allow when planning a whole project though. – HLGEM Jan 16 '14 at 16:30
I should point out this rule was developed by industrial engineers studying work for many different types of professions and that it tends to hold for all professions not just software development. I learned it as a manpower analyst studying many different things from aircraft maintenance to warehousing to human resources to software to R&D. I have seen no reason to adjust the figure in many years (woudl add up to over 20) of studying job functions and estimating project times. – HLGEM Jan 16 '14 at 18:29

This would make a good discussion for your Sprint Retrospective. In our case, we were trying to get a handle on how many non-development hours our developers were working (things that take you off-task, like an internal support call, etc), so we actually bring it up when we plan capacity at the beginning of Sprint planning.

We found that planning 6 hours of capacity/day for an 8 hour day was pretty accurate for our group.

BTW: I do agree with DJ Clayworth's answer as well. We use both points estimation (at the story level) and hours estimation (at the task level). We take velocity on the points (which lines up with the previous poster's comments). Hours at the task level help us to adjust when someone is planning a vacation or when there is a holiday during the sprint. We have found that if we cut the sprint off whenever we have hit the lower of hours or velocity, we are most accurate at predicting what we get done (unless we are intentionally ramping up velocity, like when we add a team member) – JMarsch Jan 16 '14 at 15:00

My company plans 6 hours per work day for sprints. So, 30h a week per developer, figuring 2 hours a day will be lost to meetings, pee breaks, general unproductiveness.

+1 for sometimes you gotta pee. – Amy Blankenship Jan 16 '14 at 20:58

That answer is specific to each person.

Time spent in the sprint related meetings don't allow that time to be spent on tasks, but more than that each person has other non "development" assignments. Some are managers and have weekly and monthly required tasks that don't move the project along. Others may be expected to help other workers. Some people need to keep x hours a week open for unexpected disasters. Others work is unrelated to production systems and bug fixes.

The goal is to get to a reasonable estimation of how much can be accomplished in a sprint. Pick a percentage and use that as a starting point make good estimates of the tasks, and keep track of how long it takes you. Over several sprints the team will begin to understand what each can dedicate to the task in a typical week.

Management needs to understand that this isn't a time card system.


In the past I've taken 40% of time as non-project time - email, meetings, miscellaneous, leaving 60% for projects. We'd then estimate the work required for a project, and work out project end dates in our time management tool.

Note that for devs without many extra responsibilities, I'd expect them to spend less that 40% on non-project work, and for senior devs to occasionally spend more. If you're estimating sprints, you can estimate the first one based on e.g. 40%, and then adjust it for subsequent sprints.


What I've seen work well is to include the overhead into the estimates. If I estimate a task will take me 8 hours, that doesn't mean that I'll take 8 hard working hours to complete it, it means it will take one business day (including meetings, lunch, bathroom breaks, water cooler chat, etc).

This is also the argument for Story Points. Time to finish a task will vary from person to person, but the relative effort to complete a task should be more universal.


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