How To Recognize A Self-Organizing Team During Sprint Planning

As a Scrum Master, one of  the ways you serve the development team is by coaching them in self-organization.  Several [hundred] definitions of self-organizing exist on the web but I'll use the Scrum Guide and add a point or two.

"Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. ... No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality." - Schwaber, Ken and Sutherland, Jeff. "The Scrum Guide", October 2011.

The Scrum Guide definition focuses on the development team understanding and undertaking the work they do during a sprint. The Scrum Guide specifically wants the development team to control how they do the work of the sprint. I would add to that definition two points: the development team acts as their own technical (not line) manager and the development team displays strong professional bearing, unity, and are respectful of others. This manifests itself with the development team understanding and anticipating the technical actions required to implement scrum in the most efficient and expedient manner and the development team working very closely with the product owner (PO) throughout the project.

 

Self-Organizing During the Sprint Planning Meeting

 

The Scrum Guide suggests time-boxing the sprint planning meeting at 2-hours for each week of the pending sprint but as the development team becomes more self-organizing, the amount of time necessary for planning should greatly decrease. The two main reasons sprint planning can become shorter are:

1. The development team has a very good understanding of PBI's coming into the planning meeting primarily due to helping the PO develop the PBI's and conducting product backlog grooming sessions.
2. The development team and PO work very closely together, discussing customer wants and desires, customer requirements, and customer expectations throughout the project.

Sprint Planning Meeting Part I

 

The first half of the sprint planning meeting has the PO presenting the ordered product backlog to the development team and the development team forecasting what they can do in the upcoming sprint. In an ideal first half, the self-organizing development team "pulls" off the top x items from the backlog the PO presented and adds these to the upcoming sprint. The development team and PO have already discussed the PBI's during previous grooming sessions but the PO may have made some changes since. The development team and PO review the selected items and any changes made by the PO since the last grooming session. The development team and PO then conjure up a sprint goal and the first half of the sprint planning meeting is done, probably in less than 20-minutes.

 

Sprint Planning Meeting Part II

 

The second half of the sprint planning meeting has the development team figuring out how to deliver the PBI's for the sprint. The self-organizing development team will identify enough tasks for the first few days of the sprint. The development team may re-negotiate with the PO if they determine that they cannot do all the PBI's in their present form (i.e. a need to reduce scope) or the development team may find they can do more PBI's and "pull" in these from the product backlog. The second half of the sprint planning meeting now concludes and the sprint starts.

 

The elapse time for the sprint planning meeting should be less than an hour, under 30-minutes for a two week sprint, when the development team takes on the responsibility to groom the product backlog and understand PBI's to the extent that these PBI's are "sprint ready" i.e., ready to be worked with only minimum review and recap.

 

A Clue That The Development Team Isn't Fully Self-Organizing

 

During the sprint planning meeting, the product owner pushes the requirements onto a "dazed" development team.

 

Picture a sprint planning meeting with a team only recently introduced to agile and scrum. In the first half of this meeting, the PO is presenting product backlog items to the development team. A development team member asks why a story [feature, requirement] is in the upcoming sprint. The PO and development team spend considerable time discussing the necessity and merit of each PBI for the upcoming sprint. In this scenario, there's no indication the development team understands the product backlog items and are merely reacting to what the PO has presented.

 

There are a few reasons this kind of behavior might be present:

1. The development team is in command & control mode and doesn't feel it's their place to "pull" work,
2. the product owner is in command & control mode and feels the need to "manage" the development team,
3. the development team is not grooming the product backlog with the product owner, or
4. the development team doesn't understand the product backlog is ordered.

It can be the hard for a development team used to command & control to become self-organizing, especially if the team is transitioning from waterfall. Similarly, if the PO is formally a product manager or project manager, they may have difficulties letting go of the command & control aspects of their former roles. Either of these two is likely to occur and have much the same solution, the scrum master needs to train these people on the philosophy of agile, specifically agile principles:

 

• Business people and developers must work together daily throughout the project.
• The best architectures, requirements, and designs emerge from self-organizing Teams.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

 

These agile principles coupled with the rules and practices of scrum outlined in the Scrum Guide, can start the journey towards a self-organizing team.

 

The third reason the development team is not involved may be the team isn't working with the product owner to groom the product backlog. Product backlog grooming helps to develop an understanding of the requirements both technically and from a business value (customer) point of view. The scrum master should ensure the development team and PO do grooming and may need to facilitate the initial grooming sessions to make sure this happens. The scrum master can encourage the PO and development team to work together developing PBI's for the customer requirements, develop the acceptance criteria for the customer requirements, and to discuss any risks or issues associated with the customer requirements.

 

The forth reason a development team isn't "pulling" in work from the product backlog could be they don't quite understand how the product backlog is structured. The Scrum Guide states that the product backlog has the attributes description, order, and estimate and "is often ordered by value, risk, priority, and necessity." Although the PO can decide how to order the product backlog, the product backlog is not the private domain of the PO. There should be no secrets or surprises in the product backlog. The scrum master can help maintain the transparency of the product backlog by facilitating product backlog grooming sessions and by encouraging the PO and development team to break down and write the more detailed customer requirements together.

 

Summary

 

One of the ways the scrum master serves the development team is to coach them in self-organizing behavior. The development team will become more self-organizing as time passes and one way to see this progress is by observing the way the sprint planning meeting runs. As the development team becomes more self-organizing, one effect should be the swiftness of the sprint planning meeting. This will be primarily due to the PO and development team working in close harmony together as customer requirements are developed, broken down with details added, and the PO and development team sharing a common understanding of the value of each "sprint ready" requirement.

 

Tweet