Planning Meetings Are Essential
Join the DZone community and get the full member experience.Join For Free
Discover how to increase change awareness, code quality, and maintainability through straightforward code reviews, with a simple, lightweight workflow, brought to you in partnership with JetBrains.
What does it mean to do a planning meeting "right"?
First, it must be a frequent event. If you try to run a planning meeting for six months worth of work, you'll end up spending weeks together, and you'll still miss the target. Instead try to have shorter work iterations, and plan for each one. I like the Scrum iteration lengths, which run from one to four weeks.
One of the benefits of having shorter iterations is a more regular planning meeting, but it also provides a smaller amount of work to cover. Discussing a week's worth of work doesn't take very long. It allows the team to give each feature or bug the attention it deserves. If you bring in months and month's worth of work the team will quickly start glossing over details. All too often those details are what pop up later and cause problems.
Second, the planning meeting needs the right people in the room.
The product owner (or equivalent) is responsible for collecting and prioritizing the work. They bring enough work to keep the team busy for the entire iteration. They're responsible for bringing the right work to the team, for doing the proper research before the meeting, and creating the acceptance criteria.
The developers are also present. Again, a Scrum sized team works well here. From four to eight developers are on a single team. The team looks at each feature or fix and make a few determinations. They decide if they understand the issue well enough to do the work. If they don't, they'll choose to not accept the work. It then goes back to the product owner who does more research before the next planning meeting.
Finally, the testers are in the room. As the developers are trying to decide if they understand how to code a feature (or fix a bug), the testers are trying to decide if they understand the acceptance criteria. If the testers can't agree on how to test a task, it goes back to the product owner again for more research.
The goal for each of the tasks is also important. Each task must be done within the upcoming iteration. A smaller iteration will force the team to commit to smaller units of work. If the task is an entire API for a database, the team might only commit to a dozen of the specific APIs instead of the entire system.
The discussion between the developers and testers during this meeting is also invaluable. It allows both points of view to be considered before the work is started. The alternative is to allow the developers to write the code as they understand the feature, then let the QA staff fail a feature because they think it should have been implemented differently. It's much better to iron out these differences early in the cycle, before any development or tester time has been wasted in a communication mismatch.
The product owner, our proxy for the customer, is also in this meeting, and hearing the discussion. If the team is heading down the wrong path, the PO can jump in now and keep the team on track. If you can get a "real" customer in the room, that's always a bonus, but the PO gathers opinions from a wide variety of stakeholders and prioritizes based on a big picture view. They should be talking to marketing, sales, support, executives, as well as the company's paying customers. The PO always gets the final say on what features go in and what the priority is. Their aggregated viewpoint is vital for any team that supports multiple stakeholders or customers. The idealized view of pulling in the one canonical customer into the room is rarely possible for any product company. The PO fills a vital role in the team's direction.
Once the team agrees on what a task is, what it will take to implement it, and how to test it when it's done, they then accept the task for the next iteration. This upfront communication replaces a great deal of after the fact arguments. If there's any confusion about the details, then the product owner didn't get enough information from stakeholders, and the task is rejected.
Today I sat in a client's planning meeting and heard developer's question each other's assumptions about implementation details. I heard testers question the level of testing effort a feature would require. The product owner took back some tasks for more research, and others were accepted and tackled by the team. It was a lot of fun watching the interactions and seeing how much time was being saved.
Use an effective planning meeting for short iterations, be sure you've got the right people in the room, and you'll build the right product the first time, while saving a great deal of thrashing and debate between team members. It's another great tool in your toolbox.