Actual Time to Do Development

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?

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?

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.

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.

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

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.

 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.

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!

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.

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.

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.

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.