Effective Sprint Planning
5/17/2011 10:00 AM
He who fails to plan, plans to fail. – unknown
In many ways, one of the most dreaded tasks of every iteration is the Sprint Planning Meeting. This meeting is a very important meeting, but many, many things can go wrong and make this meeting a very long and very painful experience. However, this meeting is critical to the success of the team. If the team doesn’t know what they’re doing at the beginning of the iteration, how can they commit to getting the work done?
To hopefully help ease the pain of the Sprint Planning Meeting, here are a few suggestions.
Identify Stories and Priorities Before The Meeting
This step is critical and often missed, especially on teams with dysfunctional product owners. Before the start of sprint planning, product owners and designers should have a good idea of what the story is, the rules around the story, and at least some basic paper prototypes for the story. Testers should probably have fleshed out some acceptance criteria for the stories. Without this information, the team will be unable to plan the implementation of the story with any effectiveness. Note that this implies that the team members responsible for this information have been working on the story before the start of the iteration. We find that when designers, product owners, and testers are a single iteration ahead of the development team, the actual implementation is much smoother. These team members should have a few more stories prepared than actually can be completed, just in case the team needs to throw a story out during discovery.
Ideally, the product owner will have an entire release backlog of prioritized stories. The stories should be prioritized based on the ROI for the company, which requires serious preparation and thought. Only the upcoming sprint’s stories should be fleshed out. Future stories should be left until the future.
The Product Owner should have everything they need ready for the meeting so that when questions are asked, they can quickly give answers and not resort to designing during the planning meeting.
This rule annoys many people when I first put it out. Most people are used to zoning out and not focusing on the meeting by using toys during the meeting. Toys are generally electronic distractions such as cell phones, laptops, ipads, ipods, and any other device that would prevent a team member from focusing during the meeting.
Some team members may need toys to plan effectively, for example, the team may need to know testing details from an electronic source or the product owner may want to refer to electronic documents. If they start to use those toys to zone out, then they should be reminded that they need to focus on the meeting, not on their toys. If everyone focuses, planning goes better and team members are better able to perform in the iteration.
Get Team Availability at the Start
Once your environment is set up, the very next step is to get the availability of the team. I’ve seen teams plan all of the stories that have been assigned to an iteration, irrespective of the amount of time actually available and then seen them move out more than half of those stories. That’s a waste of time! If you get the teams availability first, you can plan until the time is completely used up and then you know you are done and won’t waste time planning stories that have no chance of being completed.
You may have a product owner that resists this method of planning because they want all of the stories they assigned to the iteration completed that iteration. That’s too bad for him. The team cannot work more hours than are available, and part of Scrum is recognizing that the team has a velocity and that the company needs to deal with the reality of that velocity.
Don’t Assign Tasks During Planning
Developers will often resist this suggestion. After all, Joe is good at design and Jim is good at the back end work, so why not assign the tasks to them at the start? The practical reason is that if all of the tasks are assigned, Jim may be over allocated and become a blocking factor in the iteration. Additionally, team members may be working on stories that are a lower value to the company, simply because they didn’t have any tasks assigned to them on earlier iterations. The team is responsible for the entire iteration. Note that I didn’t say that a single team member is responsible. Therefore, my suggestion is that unless there are very specific tasks that only one member CAN do, the tasks should not be assigned. While Joe may not be as good as Jim and may take twice as long, the net effect of parallel execution may still cause the task to be completed before Jim had a chance to get to the task.
Instead of assigning tasks, the team should start at the top story and work their way down. Each story should be completed in turn. On healthy teams, a variety of team members will have tasks in a given story. On unhealthy teams, individuals will be responsible for entire stories.
Another practical reason for this suggestion is that as team members touch all parts of the application, the tribal knowledge of the team members becomes greater so the loss of any individual team member lessens the impact on the organization and on the team.
Many teams struggle to estimate accurately. Some teams even have great pressure from product owners to estimate low, rather than accurately. On one team I was working on, if anyone gave an estimate that was higher than what the product owner though was reasonable, the product owner would make loud noises and comments like “Oh, come on! That can’t take that long!” The team member would then revise down the estimate and the team would miss the iteration. This happened for more than 6 months before finally, I devised a mechanism for dealing with the situation. I call it the Uncertainty task. Basically, for each task, an estimate is given. If the team is unsure about how long it will take, or if a complication could modify the time it will take, the team adds some uncertainty time into the Uncertainty task. For example, say I’m implementing my own high powered socket server. I’m pretty sure that the TCP/IP communication will take about 3 hours to implement. However, if I can’t find a third party component to handle that communication, it may take 6 hours to complete. The 3 hour difference would be uncertainty and would be put into the Uncertainty task.
This gives the team a lot of flexibility. They can account for uncertainty and not commit to unrealistic estimates that may come back to bite them at the end of the iteration.
Avoid Design During Planning
This suggestion is difficult. Some design will usually be needed during planning, especially as the developers try to come up with tasks and discover areas that the product owner and designers may have missed. The key to success is identifying when you’re designing the story and when you’re trying to do discovery on the story. In general, if you’ve spent 15 minutes talking about a story and have added few, if any, tasks, you’re probably designing. If you’re talking about how you will implement the story (i.e. I’ll use Entity Framework, and the database design will need to look like X), rather than talking about the tasks needed to accomplish the story, you’re designing. You don’t need to know how you’re going to complete the tasks, only that the tasks need to be completed.
If you find that you can’t plan the story without significant discovery/design during planning, throw the story out and move on and give the product owner additional time to flesh out the story.
Give an Estimate and Discuss as Needed
Often, teams will fall into the trap of trying to get perfect understanding about a problem before giving an estimate. I’ve seen teams spend more than an hour talking about a problem and then deducing that the actual task would only take 30 minutes! That’s a waste of everyone’s time. Because of that, I recommend that after a task has been identified, someone on the team throws out a guess as to how long they think it’ll take. If anyone on the team disagrees, THEN have some discussion about why they disagree. If the disagreement is small (a hour or so), instead of trying to get very precise numbers, add the difference to uncertainty and move on. Teams that operate this way can complete their planning and have reasonable estimates in a few hours. Teams that need to get everything exact often will take a full day or more.
Split Up Planning
A long planning meeting is very difficult. By the end of the meeting, quality goes down, people don’t pay as much attention, and you end up with more poorly planned stories that took longer to plan. An easy way to solve this problem is to break planning up. Instead of a monster planning meeting, schedule an additional meeting during the sprint before the iteration that you’re going to commit to for planning. For example, if you normally start your sprints on a Monday, and your sprints are two weeks in length, the Monday before the start of the iteration would be a planning, and then the Monday of the start of the iteration would be a planning. You wouldn’t commit until after the second planning. You shouldn’t start the iteration without committing and since you can’t commit without planning, you should not plan for the current iteration after the start of the iteration.
Have a Retrospective about Planning
Finally, evaluate your planning process on a regular basis. Talk about what is working in planning and what is not and then make changes to make your planning more effective. Over time, the team will become better at planning and things that were useful early on may not be necessary later on. Only your team knows what works well. I recommend being stricter in the beginning for a short period of time (at least one release) and then adapting after you have some experience under your belt.
By following these few suggestions, sprint planning can be easier and more fun, and you can completed it more rapidly. Effective planning will help your team be more successful and the artifacts created can help your team become more predictable as well.
Technorati Tags: Agile