One of the key meetings for teams working with a framework such as Scrum is the planning meeting that takes place at the beginning of every new sprint. During this meeting a team will meet to plan out the amount of work they believe they can complete during that iteration. One technique teams use during this meeting is Planning Poker®, which allows them to collaboratively estimate the complexity of the work in their backlog. One of the quickest ways for a Planning Poker® meeting to lose its effectiveness is by having too many people participating at once. Amazon CEO Jeff Bezos is well known for making sure the amount of people in a meeting is no larger than the number that can be fed by two pizzas. Steve Jobs was famous for asking people to leave from meetings if they didn’t have a purpose for being there. While there are no concrete rules for what the correct number of people in a Planning Poker® game should be, here are a few things that may be helpful to keep in mind:
Size of a Scrum Team
There is no set size for a Scrum team, but the Scrum Guide recommends sticking to approximately 3-9 team members. Any smaller and it becomes difficult to complete a significant amount of work within shorter iterations. Any larger and there is too much overhead for the team to manage effectively. This guideline can also serve to give an idea of how many people should be participating in a Planning Poker® session at once. If you have more people than this it may be good to split into separate teams and have a separate Planning Poker® game (if you are at the point where you have multiple Scrum teams trying to coordinate work on a larger project, it may be helpful to look into some of the scaling frameworks that are available such as Nexus or SAFe, but that is a topic for another article).
Not Everyone Will Necessarily Estimate
Although the Scrum Master and Product Owner can be invited to participate in Planning Poker®, estimation should be done by the team members that will actually be doing the work. It is still important for the Product Owner to be present to help clarify questions for the team about functionality / scope and for the Scrum Master to provide guidance on issues that might prevent the team from moving forward with their estimations, but the team is ultimately responsible for estimating as they will be the ones committing to completing the work during the sprint.
Planning Poker® is Meant to Encourage Conversation and Shared Understanding
One of the main benefits of Planning Poker® is to enable members of the team that may have different skillsets to provide their perspective on the complexity of a particular story and identify gaps in understanding within the team. If someone points a story as a 1 and someone else as a 20, there are definitely some things that need to be discussed and clarified further. If you have a Planning Poker® game that is too large, it will become very difficult to allow everyone to share their opinion and it may take way too long to estimate each story.
Make Sure the Group is Discussing Features and Not Components
When you have a larger team in a Planning Poker® game, one of the dangers they can run into is that people get into the habit of pointing according to their area of expertise. So a team member that is more comfortable with front end development will point a “front end” story and a designer will point a “design” story and there are a few different issues with this. First, if this is happening there is a high likelihood that stories are not getting written or split correctly as they should be focusing on vertical slices of functionality as opposed to horizontally split component type stories. Another issue is that this gives the false impression of precision with the estimates. One of the primary goals of using something like story points and Planning Poker® is to avoid the trap of trying to come up with estimates that are too precise and that will likely be inaccurate. Finally, when teams estimate along these lines it reduces the amount of discussion around each story (see point #3) and everyone will be less involved when it comes to a story that they don’t consider to be in their wheelhouse.
Summary
As with most things in Agile there are no concrete answers for what works best. The most important thing is to continuously inspect and adapt as the project progresses, and focus on enabling good conversation within the team to build a shared understanding of what they are working to accomplish. This will take time and practice, but having a manageable team size is good place to start.