photo1Peak load is an engineering concept that has found its way into software development and maintenance conversation.  In electrical engineering, it is a measure of the maximum electrical demand a system will make on the electrical grid. Software testers apply a version of this concept in stress and load testing scenarios. Peak load is a spike over a specific period of time and not a sustainable level of performance. When applied to a software team, the peak load is how much additional work a team can do for a short period of time. While the principles in Agile Manifesto call for a sustainable pace, all teams know that they can call on a reserve of energy for a brief period of time to accomplish a specific goal.

In classic plan-based projects, we have all observed teams expending huge amounts of energy just prior to the overall due date or implementation. Similar patterns of behavior can sometimes be seen on sprint teams when the team is rushing to complete their committed stories as the last day of the sprint approaches.

In a normal Agile team, the average velocity (the average number story points or function points completed) is a good proxy for a stainable pace. I generally suggest that a team can occasionally increase its velocity by approximately 10 – 20% for a single sprint. For example, a team that averaged 20 function or story points might be able to commit to deliver 22 – 24 points as their peak load. In some more extreme spikes, there are frequently stories that are not completed or have quality problems.  However, this all assumes that the average velocity is really the team’s norm, rather than something they have achieved while being whipped. The problem with a team working at peak load is that sooner or later the team will have to revert to the mean, which means that it will look like the team is underperforming. If the team’s performance is graphed you will see a classic saw tooth pattern. The lack of consistency can hurt the team’s ability to deliver by first exhausting the team and them creating a scenario where they publicly underperform.

In electrical systems pushing a machine or appliance to peak load stresses the system and generates wear and tear. In the long run, this leads to breakdowns and the need for repairs. Teams are no different.  The big difference is that, given a compelling goal and then time to recover, teams can rise to a higher of performance, to a peak load, for a short period of time without have to be put in the shop for repair. Pushing a team to a peak load should be used judiciously.