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.

Meet Carrie (pretend that is her real name).  The team she is part of is “sort of” collocated.  Most of them occupy a portion of a massive cube farm that makes collaboration a one or two person event at a time.  The Daily Stand-Up meeting is a sit-down and lasts about a half-hour.  On the other hand, they joke and laugh and have a good time for about 15 minutes before settling into the real purpose of the meeting.  I asked Carrie, “Does it help?”

The answer to this one question convinced me this was the perfect thing to do.  Carrie responded, “Yes, this is the time where they get to bond and have fun together.  There are no similar interactions like this any other time. It really brings the team together!  Sprints go much better since this started.”  I thought, “What a great use of 15 minutes!”

I realized I had seen this before with an executive team using Scrum practices to run the company.  A Product Backlog and Sprint Task Board covered part of their beautiful view in the meeting room that adjoined the CEO’s office.  They were faithful with Sprint cadences, periodic retrospectives and velocity tracking.  They used some kanban practices to pull their stories through.  It was very focused and productive.

Yet, the daily meeting with all the CxO’s, and legal counsel took 30 minutes every day.  It always started out with good-humored needling, a touch of politics, local business happenings, and even a few pranks.   Most of it was extremely funny and no one was “safe.”  The standard meeting goals were always accomplished, and the group would head back to their offices.   It took me awhile to realize this meeting was a bonding activity more than an agile meeting.  They had adopted their “daily 15 minutes of fun.”

Sometimes we forget how much we work at a break-neck pace.   Sometimes we need to relax and have some fun.  Like continuous integration, where we bite off small chunks of “pain” instead of enduring excruciating integration phases, frequent bits of fun is a great way to do business.

For those of us lucky enough to be on collocated teams, we may not need extra fun.  For those of us that need a bit more fun at work, try something new.  I believe developing great software is both a creative and technically challenging endeavor. If doing it is not fun then something is wrong. We must figure out why it is not fun and do something about it.