The Six Hour Day

---

Our Motivation and Reasoning

At [CompanyName], our time tracking data shows that our devs will on average spend more than 7 hours actively working each day, sometimes closer to 9 hours on tighter projects. In order to set ourselves up for success we only plan for 6 hours a day, knowing that everyone will be putting in additional effort.

Our methodology to achieve this is as follows. The official work day is from 0900 to 1700, which equates to an eight hour work period. Within that, one hour is mandated by law as being a lunch break over which we have no jurisdiction and is the employee's time to use as they wish. That leaves seven potential work hours. In an ideal world, everybody would work those full seven hours. However, that is unrealistic as there are a number of acceptable things that generally happen on any given day. For example getting up for a glass of water or cup of coffee, receiving a delivery, dealing with a burst geyser, having a pee, etc. Therefore, we only expect six hours of meaningful logged time each day from our staff.

Any time spent actively engaging on a project counts towards this number. This includes project meetings (standups, retros, team alignment chats, etc), planning, research, making builds and obviously active development and bug fixes.

An additional consideration for the six hour day is that because development work is mentally taxing, we need to ensure that our devs remain as fresh as possible for as long as possible. If we lean on them too hard they will become less productive and more mistakes will be made, ultimately resulting in inferior products and missed deliveries.

Thus our standard for quoting on any development work is for a six hour day, as that is what can reasonably be expected.

Sprint Ceremonies

If we consider the usual sprint cycle on a development project, we generally expect the following meetings/calls to happen within each cycle:

• Daily standup (9 x 0.5hr = 4.5hrs, assuming no standup on team planning days)
• Planning with the full team (1hr)
• Retro (1hr)
• Internal Demo (1hr)
• Client Demo (1hr)

These items listed above add up to 8.5hrs, which is more than a full day per sprint of just ceremonies for each developer and their project manager. These times are variable per project, but illustrate the cumulative effect of the ceremonies within each cycle.

Developer Requirements

We also need to factor in detailed sprint planning for the devs so that they are fully aligned on a technical level in terms of their assigned tasks for the sprint. Creating builds at the end of each sprint for both internal and client feedback also requires dedicated time to ensure the build matches the expected quality at that phase of production, and to prepare build notes for distribution. Ideally we would add the following to each sprint:

• Planning (6hrs for each dev)
• Builds (3hrs for one dev)

The final consideration with regards to the amount of time available in each sprint is that of public holidays. All things considered equal, public holidays in South Africa account for 0.25 days per week, so factoring this into the initial planning can help mitigate some of that time loss. Depending on when a project is scheduled during the year will change the impact of public holidays, but assuming a longer project this will balance out over the year.

Sprint Calculator

This sprint calculator spreadsheet shows how the sizing for a project can be translated into a number of sprints once all of the above has been considered. This accounts for public holidays, all ceremonies, dev planning UAT and deployment time. There is no buffer allocated here and the calculation is based purely on the presented scope as it has been sized. There should be some thought applied as to what an acceptable buffer might be in order to allow for a small amount of scope creep and for overruns where items take longer than expected due to unforeseen issues. The dev day rate can also be adjusted to determine the fee for the project.

This sheet will be made available [here].

Additional Considerations

As with all projects, there is some leeway on certain items that will affect the above. For example, reducing the number of required daily standups by half will shave two hours off the time needed for ceremonies. Or reduce the time for each of them to 15 minutes. Posting digital YTIs in the relevant Slack channel will serve the same purpose and require less time per person to complete and promote asynchronous work.

Retrospective meeting time could be reduced by employing an async model where everyone provides their feedback prior to the meeting, so that the call is purely for discussion of the points. This would allow all project participants to provide their feedback during a natural pause in their workflow.

From the dev side, once there is momentum on a project we will generally spend a bit less time on detailed sprint planning as once the foundational aspects are in, most systems build on that knowledge and those prior decisions. There is time to be gained here over the course of a project, but it’s difficult to quantify up front as it will vary based on the complexity of what we’re building as well as the overall project timeline.

Shorter projects will always be more impacted by the ramp up period at the outset, and longer projects will gain more efficiency over time. There is a consideration to be had for scheduling numerous projects at the same time that have common features and frameworks, and then switching devs across those projects to also play to their individual strengths. If we treat that as a single project with multiple apps, following the same pipeline, there would be even more efficiencies to be gained over time. For this to to work however will require multiple projects to be more aligned in terms of dates, scope and technologies.

---