Nature abhors a vacuum, thus a line forms.

One of the common refrains in management circles is that work expands to fill the time available. It is know as Parkinson’s Law. The implication is that if work expands to fill available time, then managers should overload backlogs to ensure time is spent in the most efficient manner. Historical evidence from the UK Civil Service and experimental evidence from staffing contact centers can be backs up that claim. Given the existence of data that proves Parkinson’s Law, many IT managers and project managers strive to ensure that full utilization is planned and monitored.  The focus on planning 100% utilization in software teams is potentially counterproductive because it generates planning errors and compression.  

In classic project management some combination estimators, project managers and team members build a list of the tasks needed to deliver the project’s requirements.  These work breakdown structures are ordered based on predecessors, successors and the teams capacity.  Utilization of each team member is meticulously balanced to a prescribed level (generally 100%).  Once the project begins, the real world takes over and WHAM something unanticipated crops or a group of tasks turn out more difficult than anticipated. These are schedule errors. Rarely do the additions to the schedule ever balance with the subtractions.  As soon as the plan is disrupted something has to give. And while re-planning does occur, the usual approach is to work longer hours or to cut corners. Both cutting corners and tired team members can and generally do lead to increase levels of technical debt

Over planning, also known in many circles as stretch goals, generates immediate schedule compression. In this scenario, the project is compressed through a number of techniques including adding people to the team, working more hours or days or the infamous step of cutting testing. These same techniques are leveraged in projects where planning errors overwhelm any contingency.  Schedule compression increases risk, cost, team stress and technical debt.  Compression can (and does) occur in classic and Agile projects when teams are pushed to take on more work than they can deliver given their capacity. 

In projects with high levels of transparency these decisions reflect tradeoffs that are based on business decisions. In some cases the date might be more important than quality, cost and the long term health of the team.  Making that type of decision rarely makes sense but when it does it must be made done with knowledge of the consequences.

Agile teams natural antidotes for Parkinson’s Law: the prioritized backlog, the burn down chart and the daily standup/Scrum meeting. On a daily basis team members discuss the work they have completed and will complete.  When the sprint backlog is drawn down, the team can (with the product owners assent) draw new stories into the sprint.  The burn down chart is useful to help the team understand how they are consuming their capacity to complete work. 

Whether you use Agile or classic project management techniques, Parkinson’s Law can occur. However the typical response of planning and insisting on 100% utilization might lead to a situation where the cure is not worth the pain delivered in the treatment. In all cases, slack must be planned to account for the oft remarked “stuff” that happens and teams must be both responsible and accountable for delivering value of the time at their disposal.