Maxing Out the Team

Remember the Scrum secretary we described in Chapter 7, ​Embracing the Scrum Master Role​? That person is making another appearance here. Here’s what we’ve seen this type of person do more than we care to admit:

The Scrum team gathered for the sprint planning event. As the development team watched, the Scrum master dragged PBIs from the product backlog into the sprint backlog using his favorite digital tool. He stacked as many product backlog items into the sprint backlog as capacity would allow, in order to maximize utilization and keep everyone on the dev team as busy as possible during the sprint. (The product owner and Scrum master often pushed the dev team to “take on more” and to complete more work than in past sprints.) The outcome of this event was the dev team committing to finish all the work in the sprint backlog. There was no sprint goal, only a giant pile of work for the development team to complete during the sprint.

We have seen this kind of behavior many times—development teams driven by the product owner and/or the Scrum master to take more work and commit to completing that work. This arises from a misinterpretation of Scrum: Many teams think that during sprint planning, a team must load the sprint backlog with as much work as possible and commit to completing that work. As a result, daily scrums center around how to stay busy. Each sprint comes with a deadline of work that has to be completed. It takes long hours and fortitude to complete all the work by the end of each sprint. The quality of the product is low, and the word “value” seldom enters into the team’s vocabulary.

The purpose of sprint planning isn’t to fill the development team’s “plate” so that the plate can be “cleared” during the sprint. Rather, sprint planning is meant to create a starting plan for the sprint which includes a sprint backlog, forecast, and a sprint goal. The plan that is created in sprint planning will change. The sprint backlog emerges: When complex work is started, additional work is found. The point at which a team knows finitely how long it will take to complete a PBI is when the PBI has been completed.

Maximizing utilization of employees is an archaic way of thinking that has negative consequences on knowledge workers such as software developers. It’s based on the belief that we know explicitly what needs to be done to finish a piece of work. Centering your sprint planning event around maximizing employee utilization will result in:

• Low product quality because the race to finish items becomes the most important success factor.

• Low morale as a result of sprints becoming mini “death marches” and employees being viewed as “resources” instead of, well, people.

• A lack of ownership of the intended value of the product because “clearing the plate” becomes the problem to solve—instead of pleasing the customer.

• No room for innovation because there is a list of things to do and that list fills—or is larger than—the time the development team has to accomplish it.

• Instead of conversations about being effective and delivering a great product, the team’s conversations are about maximizing the efficiency of individuals.

Planning to capacity leaves no room for the unplanned work that always crops up when the development team faces a complex problem. The giant list of tasks that need completing becomes the team’s focus instead of the value they’re creating. This way of thinking is often coupled with extrinsic motivators like annual reviews or bonuses. This further drives development team members to stay busy so as not to meet negative consequences. Your product will reflect this mentality.

Joe asks:

Is sprint completion percentage a good metric?

Sprint completion percentage is a metric some organizations use to see if teams are finishing all their sprint backlog items during a sprint. It bears no value in determining the effectiveness of a Scrum team. A team could finish all their sprint backlog items but deliver low-quality work that adds no value to the product. Conversely, a team could regularly not complete their entire sprint backlog but deliver high-quality, valuable increments. Bottom line: Sprint completion percentages are useless and you shouldn’t use them.

This situation might be a reflection of organizational policies that have been in place for many years and can take many years to unwind. You have to start somewhere, so here are a few ideas:

• Make sure the Scrum team leaves sprint planning with a sprint goal. Advertise the goal and celebrate success in achieving it.

• During sprint planning, ensure that the development team, not the product owner or Scrum master, is moving product backlog items into the sprint backlog. This is a subtle way to create ownership.

• Resist the temptation to assign items to individuals during sprint planning. Give the development team the opportunity to collectively own the sprint backlog.