Get certified - Transform your world of work today


Sprint Planning: Better Together

10 July 2006

Mike Cohn
Mountain Goat Software

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:

  1. The whole team selects the product backlog items they will work on during the sprint.
  2. 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.
  3. 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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 5 (3 ratings)


Deepak Joshi, CSP,CSM,CSPO, 10/16/2014 9:46:53 AM
Hi Mike,I completely agree.

Generally, when the teams are transforming from Waterfall to Agile, estimations are done by specialists due to the old routine. At times most of the team mates of new agile team had worked together in the projects which followed Waterfall methodology and accepted that the ways estimations were done and committed, the specialists know better.

While sometime it is taken as granted in new and immature agile teams which do not have understood the significance of all the ceremonies of agile, some of the team mates feel that once the decisions have to be made by these specialists and they will be dominating the ceremonies, what is the use of attending such ceremonies. Demotivated team mates feel that instead of attending these ceremonies they can put this time for some other purpose.

One other reason is being monotonous and not creating enthusiasm in these ceremonies. Ceremonies are for Transparency, Inspection and Adaptation and when due to any reason, no significant outcome or improvement is visible, it creates dullness. This is true that apart of other responsibilities, facilitator needs to be energetic and innovative. Bringing new scrum games also play great role in such cases where team mates show unwillingness to join the ceremonies due to such dryness.

Scenarios like these need to be looked into by a facilitator and encourage all the team mates not only participate but participate together.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up