By Mike Cohn
While teaching a recent Certified ScrumMaster class I was asked what a ScrumMaster should do about a team member who doesn’t want to participate in a sprint planning meeting. In this specific case, the question referred to a team member who told the others, “Whatever you come up with is fine with me.” As you’d expect, I answered that the reluctant team member needed to participate in sprint planning. I recommended that the ScrumMaster tell the team member that while he appreciated his conscientiousness in seeking to avoid unnecessarily wasting time, the value of his participation in the meeting would outweigh any perceived waste.
Most of us know what to do in a case such as this, and wouldn’t consider letting a team member skip sprint planning meetings. Yet, many ScrumMasters do allow and even encourage a similar practice: rather than having the whole team work together to plan a sprint, different specialties within the project team plan independently, each focusing solely on “their part” of the sprint plan. Independent plans are then consolidated. The usual sequence of activities goes like this:
- The whole team selects the product backlog items they will work on during the sprint.
- Team members divide into specialties to discuss what will be needed of their specialty in order to deliver the selected product backlog items. That is, the programmers are in one room discussing what programming tasks will be needed while the testers are in another room discussing what testing tasks will be needed, and so on.
- Everyone reconvenes for a very short meeting in which the plans are combined.
I find this approach to be no better than allowing a team member to skip sprint planning entirely. Three serious things go wrong when teams take this specialization-based approach to sprint planning.
First, the plans that result are not as good as the plans created through a whole-team approach. When specialties plan independently, the team loses the opportunity to identify valuable tradeoff opportunities. For example, I’ve been in countless sprint planning meetings in which a tester comments that testing a particular product backlog item will be much harder than might have appeared at first glance. In many of these cases, the programmers then offered to alter slightly how they would program the feature so that it could be more easily tested. Perhaps they could provide the tester with a programming interface into the feature, perhaps they could expose the feature through a different layer of the architecture, perhaps they could provide an alternative user interface, and so on. When specialties plan independently, these discussions do not happen and the opportunities are lost.
Second, the individuals of one specialty do not develop a shared understanding of the tasks and estimates of another specialty. The level of understanding necessary isn’t such that one group could do the work of another; however, the more the whole team comes to a shared understanding of the work to be performed, the better. Sprint planning meetings are about far more than just identifying tasks and putting an estimate on each. Sprint planning meetings are about discussing the work to be performed, understanding what the product owner wants, how we might collaboratively deliver that, how we’ll collectively address risks, and so on.
Third, when the tasks of the sprint plan are identified independently, the team does not establish a “we’re all in this together” mindset. Instead your specialty’s estimates are yours and my specialty’s are mine. When we start off on this incorrect footing we are very unlikely during the sprint to share the burden of finishing all of each specialty’s work. Each team member will focus on finishing the work that was identified by their specialty. This often results in symptoms such as the programmers continuing to program features that the testers won’t have time to test during a sprint. When a sprint is planned by the whole group, if the programmers find themselves outpacing the testers during a given sprint, some of their time usually shifts to completing testing tasks.
Sprint planning needs to be viewed as a collaborative, whole-team effort. When sprint planning is viewed solely as the sum of individual or specialty-based planning, both the product and the team will suffer. To avoid this, ensure not only that all team members participate but that they all participate together.
