How Long is a Developer Day?
The impact of meetings on agile development teams
Introduction
In my article, “If Estimating Work Needs To Be Reliable, Why Use Story Points Instead of Time?”, I discuss the reasons for my preference for advocating the use of story points for estimation of Product Backlog Item size. Although my preference is to avoid using time for this purpose, time is still an important consideration when optimising workflow in the team.
There are only so many hours in a day. The same holds true for the developer day, especially as we embrace the concept of sustainable pace. For guys working a typical forty hour week, we can then divide that into eight hour days for a five day working week. This is a common assumption but does it really hold true?
Capacity
For those of us using story points, we consider capacity of a Sprint/Iteration in terms of the team’s average velocity. We have sprint events to plan in, which have maximum time-boxes, and the time taken for each of these events is averaged out in the team velocity. They do, however, consume time.
In an ideal world, they would be the only meetings arranged during the sprint however reality does not always with the ideal. Accepting that meetings will take place, additional to the scrum events, we should have an approach to maximise the benefit of participating in those meetings. Key to that is identifying objectives.
Eisenhower Principle
This principle is a useful decision making tool in determining priorities. The principle discusses the consideration between what is important and what is urgent. Two useful premises are that:
- Important activities have an outcome that leads to us achieving our goals, whether these are professional or personal.
- Urgent activities demand immediate attention, and are usually associated with achieving someone else’s goals.
You can read more about the Eisenhower Principle here.
In making the decision on whether or not to attend a meeting, we should evaluate the objective(s) of the meeting and also seek to assess the importance to the individual or team with regard to achieving the goal(s) of the sprint. If you decide that attendance is not important for you or the team, could the meeting be recorded? Alternatively, perhaps meeting notes could be provided after the meeting.
Meeting Duration
Two of the scrum values, respect and focus, are particularly relevant for the conduct of meetings. First of all, respect the time that everyone is giving up for the meeting and attend on time.
Parkinson’s law states that “work expands so as to fill the time available for its completion”
Parkinson’s law can also be witnessed in meetings where tangential discussions can take place that fill the allotted meeting time. This is where focus can help. Identify the objectives for the meeting and stay focused on meeting them. Once achieved, end the meeting and give any remaining time back to the attendees. We can go on to see the reasoning for this.
Scrum Events
What we have said about meeting duration also applies to scrum events. They have a maximum time-box but do you really need to take all of that time? That is a judgement call. I refer back to the point of identifying the objectives for each of the events. It is important for the team to realise the benefits to the team of each of those events, but that is a separate discussion.
Time Consumption
Whatever event during a sprint that does not involve developing/testing code, consumes available development time. Effectively, it is reducing the average developer day. Let’s look at that in some more detail. In this example, for illustration, we shall consider a two week sprint.
The time-boxes for the scrum events are as follows:
- Sprint planning: 8 hours for a one month sprint, so 4 hours in our example.
- Daily scrum: 15 minutes each day.
- Sprint review: 4 hours for a one month sprint, 2 hours for our example.
- Sprint retrospective: 3 hours for a one month sprint, 1.5 hours here.
- Product backlog refinement: Should not take up more than 10% of the developer capacity for the sprint.
“Don’t throw the baby out with the bathwater”
derived from the German proverb, “das Kind mit dem Bade ausschütten”
I have seen many teams artificially shorten scrum events due to a lack of appreciation for what they should be trying to achieve in those events. Observing the caution in Parkinson’s law, we should not use the full time-boxes for the sake of it. We should clearly identify our objectives in each of those events and then end the meetings once we have achieved them. The entire scrum team should be clear on the benefits to the team of the scrum events. The actual time required will depend upon the experience of the scrum team members. The Scrum Guides give a full explanation of each of the events.
Let’s take a look at what all of this means in numbers. Based on the two week sprint, eight hour day. Using only the formal Scrum events full time-boxes we have a remaining, average daily, available production time of seven hours.
Not too bad so far. Let’s add the 10% maximum for the refinement sessions; 10% of the remaining time that is, so approximately seven hours. In this example, that is split in to two sessions of 3.5 hours. I know! You may not need all of this time; bear with me.
So, what we have now — for an eight hour day — is almost a 25% reduction of the available production time each day on average. Something that compounds this impact is that almost invariably there are various other meetings that invite developer participation. We can add a few, just for illustration to help make the point of this article.
This is not intended to be an exhaustive list but hopefully serves to illustrate the potential impact of meeting frequency and duration on average available production time. In this illustration we are now below 75% of the average day available for production.
The Scrum Master can certainly coach the team and organisation on this theme but understanding the issue can help people to be more receptive to the point being raised.
“When the student is ready the teacher will appear. When the student is truly ready… The teacher will disappear.”
― Tao Te Ching
This is one piece of the production time puzzle. What the developers do with that available time is another coaching point. A lean agile approach in reducing the impact of the seven wastes of software development will take us further in efficiency. The timing of meetings can exacerbate what we have already discussed even further. There is an inevitable wind-down before meetings and an adjustment of focus on returning after the meeting. A full explanation of the seven wastes is beyond the scope of this article, however I hope I have managed to give a picture of the context within which they reside.
Summary
What I am looking to communicate here is the need to be mindful of meetings and the need to extract maximal benefit from them. Perhaps we should look at the meetings that developers are invited to and have the conversation with the team. What are we getting out of these meetings? Who needs to be there? Are there any meetings that we could decline to get back some time? How efficient are we in our scrum events? Do we understand our objectives and how could we conduct them more efficiently.
Do you want to write for Serious Scrum or seriously discuss Scrum?
