Getting Agile

In the agile community there are some common practices that are either seen as valuable or to be avoided. Two of those practices are estimation using Planning Poker and Sprint Planning task breakdown. The focus for many teams in these practices is on the estimates themselves and how “accurate” they are. It has been my experience that accuracy in estimates is not possible and belief in their accuracy leads to wasted effort and failure to meet commitments.

Planning Poker

Teams often ask “what if we estimate wrong”. To me this is reality for any estimation process. By definition we are “guessing” (hopefully educated) and therefore our estimates will be wrong. The idea is to be consistent rather than precisely wrong. This allows teams to better predict based upon similar constraints to earlier iteration how much they will be able to deliver in the next iteration. Rather than basing estimates on predictions of the future we are basing them on what we have done in the past.

The use of “estimate size; derive duration” method of estimation helps teams gain knowledge about how much they can deliver in a time-boxed iteration. One technique to generate the estimates of size is Planning Poker. Most teams start out attempting to get the estimate exactly “right”. I will not advocate that this is bad to do but I do think that teams would find Planning Poker and other exercises for estimating size more valuable if they focused on the communication that occurs. The real magic of Planning Poker is that cross-functional team members and team members with different perspectives are able to share their knowledge with each other and ultimately meld the points of view into an approach for implementing a user story. A focus on communication allows teams to capture important information, constraints, and decisions around a particular user story and better understand as a team what is involved in its delivery.

Sprint Planning Task Breakdown

When teams come together for the first time in organizations where they have been separated by functional role or even teams that haven’t worked together before, the act of breaking down user stories into tasks assists teams with communication. If the Product Backlog describes the “what” then the Sprint Backlog describes the “how”. Tasks are tools for capturing the “how” and makes it visible to the entire team. Instead of team members with different functional roles, team members describe how they will contribute to the potentially shippable product increment delivered by the end of the iteration. Instead of focusing on the perfect tasks and estimates on those tasks, I believe it is more valuable to have a shared understanding of how the team will deliver the user story. Tasks are just the tool to make visible that shared understanding and we should focus on the communication between team members and capturing the important details that enable successful delivery.

Now, tasks are not the only way to get a shared understanding, of course. I have been on teams where we would talk, draw a little picture on a post-it note, and then agree with as a team that was enough to plan with. This was with an extremely experienced Scrum team that worked together or around each other for a long time. When a new team comes together in an organization that has not created user stories before they have difficulty getting “right-sized” user stories for the team. Most of the time there seems to be some difficulty breaking them down items into small enough items for the team to deliver within 1/2 of a sprint’s length. As the team does task breakdown they are better able to capture details that help them work out how the whole team will contribute to the user story. This leads to recognition of user stories that are too big or even those that are ambiguous.

New teams using task breakdown in their Sprint Planning meetings should focus on how they communicate with each other and make sure that each member of the team is heard. This will lead to a better shared understanding of how they will work together and deliver successfully.

Focus on Team Communication

Here are some things that teams can do to help their communication in planning:

• Make sure all team members are heard so they will feel compelled to participate
• Always discuss reasons why you, as a team member, are not satisfied with the plan
• Don’t push your estimate or task breakdown suggestions on the entire team
• Cross-pollinate within your team across functional role boundaries to better understand other roles
• Use past experiences and story-telling to describe reasons for a particular position
• Use whiteboards and design techniques to visually portray ideas

Hopefully a focus on team communication will help make estimating and task breakdown a more valuable experience for your team. Please share things that your teams have done to help focus more on communication to increase shared understanding by leaving comments on this blog entry. I look forward to hearing from you.