Skip to main content

Actual Time to Do Development

Last post 09:01 pm August 26, 2018 by Simon Mayer
12 replies
02:07 pm August 19, 2018

I recently took the PSM-I course and tried to calculate the actual amount of time a developer has in a 2 week sprint to do development work.  I assumed developers average two, 30-minute meetings every day and five, 60-minute meetings over 2 weeks.  I also included 45 minutes for lunch.

  • Daily Scrum is .25 hours x 10 is 2.5
  • Sprint Planning 4 hours x 1 is 4
  • Sprint Review 2 hours x 1 is 2
  • Retrospective 1.5 hours x 1 is 1.5
  • Lunch .75 hours x 10 is 7.5
  • Two 30-minute meetings x 20 is 10
  • One 60-minute meeting x 5 is 5

Two Week Total is 32.5 hours

In an 80 hour work week, that only leaves 47.5 hours/per developer to do development work.  Is that seem correct and what development teams achieve? If this is the case, do product owners realize this?  How does this affect productivity expectations?  

Thanks,

Bob


02:37 pm August 20, 2018

Hey Bob

If only it were that "simple" :)

The golden rule is that one can never calculate precisely how much time is available for work. Work of any kind. That's why one estimation method is ideal days. Sure, you can estimate and do high level planning, but unknowns usually impact the plans.

Furthermore, I'd like to point out that, while there is a timebox rule (so for a 2 week sprint, the rule is max. 4 hours for planning), it doesn't have to be interpreted as if it's a forced duration. That is, if planning ends in 108 minutes, off you go, no need to use the whole 240 minutes. Applies to all events, not just planning.

Also, note that a key meeting (backlog refinement) could take up to 10% of the development team's workload... but guess what... if the product is new, or there are significant challenges, in an initial (or critical) point in time, they will likely spend way more than 10%, because there are too many risks and unknowns for them (and, obviously, the PO) to get a decent understanding of what's what.

And so forth...

Question: why are you interested in calculating a developer's time - and productivity? What purposes would it serve? A manager's?


03:33 pm August 20, 2018

I recently took the PSM-I course and tried to calculate the actual amount of time a developer has in a 2 week sprint to do development work.

Did you include Product Backlog refinement in the calculation?

Anyway, if the events and other meetings a Development Team attend do not add value to development, then that would be a problem. Do you have reason to suspect that any might not be adding value?


04:39 pm August 20, 2018

In an 80 hour work week, that only leaves 47.5 hours/per developer to do development work.  Is that seem correct and what development teams achieve?

It is probably worse than that.  I forget the source, but I read the average developer only spends 3 hours per day writing software.

How does this affect productivity expectations? 

The issue that impacts productivity the most is multi-tasking.  Eliminate as many interruptions as possible.  Meeting free days, with the exception to the Daily Scrum, is often helpful to provide focus.

If this is the case, do product owners realize this? 

If they are part of the Scrum Team and working closely with the Developers, one would worry if they didn't realize this.

As the Scrum Guide tells us:  Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum...The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.


05:31 pm August 20, 2018

Thanks everyone for the quick response.  I didn't mention this before, but I am on multiple Scrum projects (with varying levels of involvement) so the time set aside for Scrum events adds up.   

Eugene, I wanted to quantify the amount of time all of the Scrum events took over a 2 week sprint.  If 40% of your time is spent in meetings, as a developer myself, I have to adjust how I manage my priorities against the sprint backlog.  Without the Scrum events, I could expect to work on development tasks for 7 hours or more a day.  With the Scrum events, that time has been reduced to less than 5 hours per day.

To Ian's point, I didn't explicitly add 10% for backlog refinement but you could assume it might be the topic of some of  those 30 minute meetings.

I would also add that I'm fortunate to work for an organization that prescribes to 35-hour work weeks, so my development time is even less. 

Chris, thank you for reminding me about multi-tasking, unfortunately the reality for me is wearing multiple hats in the IT department.

Perhaps, maybe the answer in my case is longer sprints.

 

 


06:10 pm August 20, 2018

Bob, I did a little adaptation in my teams here in my company.. 

For on Sprint I let them work for 10 straight working days, (not including holidays and weekends), and between Sprint I get one full day where I facilitate all the big cerimonies. It's working really smooth here, that my suggestion :) 


09:41 pm August 20, 2018

I didn't mention this before, but I am on multiple Scrum projects (with varying levels of involvement) so the time set aside for Scrum events adds up

Bob, should we conclude that you are actually working as a development member on more than one Scrum Team?   If that is the case, your issues may have nothing to do with Scrum, and everything with being partitioned by your management to work on multiple initiatives, and not allowing you to be a dedicated Development Team Member on a single Scrum Team.

One thing I would strongly suggest against though is extending the length of your sprints in response to your capacity issues.   Such a tactic would only mask your over-utilization, and not address the issue.

 


04:09 am August 21, 2018

 Is that seem correct and what development teams achieve? If this is the case, do product owners realize this?  How does this affect productivity expectations?  

 

What the Product Owner cares about is the value of the product, not how much time the Developer Team spends on the actual development work.

These Events, as defined by Scrum Guide, are designed to reduce unnecessary meetings and waste and to enhance the quality and value of products through these meetings.

 


06:20 am August 21, 2018

If this is the case, do product owners realize this? How does this affect productivity expectations?

I would hope that productivity expectations are set empirically. Perhaps by looking at past outcomes, and trends, in order to forecast what can be backed up by evidence.

I would expect Scrum Teams to inspect and adapt, in order to strive for better outcomes.

Also, I think it's appropriate to consider that Scrum events are timeboxed (and most other meetings should be). Are the full timeboxes always being used? I would hope not!


01:55 pm August 21, 2018

Without the Scrum events, I could expect to work on development tasks for 7 hours or more a day.  With the Scrum events, that time has been reduced to less than 5 hours per day.

Sure, but:

- How would you make sure that what you were doing added value to the product?

- How would you know whether a fellow developer was working on something that might interfere with your work?

- How would you know whether your team was on its way to meeting its goal?

- How would you even know what that goal was?

- How would you know what to work on next?

- How would you gain a better understanding of the product you were developing?

- How would you ever improve your way of working?

 

The Scrum events serve purposes. You can't just eliminate them and claim that you now have 7 hours a day to code, because the issues the Scrum events adress don't go away. Inspection & Adaption is key in delivering complex products. You need to take your time for that.


05:13 pm August 22, 2018

For on Sprint I let them work for 10 straight working days,

Thiago, thank you for sharing.  I am much more interested in hearing how Scrum's team perform with limited resources like developers on multiple teams rather than Scrum philosophy.  I appreciate everyone sharing their knowledge on Scrum but my time calculations for a 2 week sprint really can't be adjusted enough to accommodate a developer on more than 2 projects at the same time.

I'm already sold on Scrum as a framework and I'm drinking the Kool-Aid but I can't be the only developer that working on more than one thing at a time.


09:21 am August 24, 2018

For on Sprint I let them work for 10 straight working days

I apologize if I'm misunderstanding Thiago, but, in my view, this is an incorrect approach. The SM or PO does not decide, independently, "I let them work for x days". There are some basic rules in the Scrum Guide, and these must be followed (including DT's self organizing, deciding how to deliver a done, potentially shippable, increment). For just about everything else, I'd argue it's a team effort towards discovering ways to improve, how to work as a Scrum team, what the sprints should be like, etc.

So a SM or a PO should never dictate or rule on topics where the group wisdom comes in place.

Also, working on 10 straight days, "and between Sprint I get one full day where I facilitate all the big cerimonies" may be a reasonable approach if the team is collocated and stakeholders are in the same building - so running the review, retrospective and planning can certainly be run in a day. But how about backlog refinement?

I am much more interested in hearing how Scrum's team perform with limited resources like developers on multiple teams rather than Scrum philosophy.  I appreciate everyone sharing their knowledge on Scrum but my time calculations for a 2 week sprint really can't be adjusted enough to accommodate a developer on more than 2 projects at the same time.

That's actually the whole point, Bob. If there are limited resources, with developers on multiple teams, you're basically missing out most of the framework's benefits and you may want to explore other ways of working (methods). Sure, in theory you have multiple Scrum teams, but in reality you have none. 

Like my predecessor, I'd advise against increasing the sprint length - sprint length isn't the problem. Maybe the organization could reconsider the priorities (and hence the projects), order it by importance/business value, and that start top down with dedicated teams (even 2 developers in a team to start with) that work on a single project s(or max 2 projects) at a time? Would this be appropriate? 

And again, as already mentioned above, don't focus on "time calculations", neither you, nor anyone else. Sure, you can log time in JIRA (or whatever tool you use), but focus on product and value per sprint. Not on time available, time spent, story points "completed", etc.


09:01 pm August 26, 2018

Bob, do you consider it helpful that you are a member of multiple teams?

If you agree that being in multiple teams is the root issue, then perhaps you can help make that obvious to team members, managers and other colleagues in a position to help you. A good Scrum Master should be able to help you make this transparent, and find better alternatives.

If you are the only one with skills that are required by multiple teams, perhaps your role should involve coaching some of the teams to be self-sufficient. This may allow you to find a position in just one team.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.