Avoiding planning failures with a very short serious game

When my team designs products, builds campaigns or change management programs, estimating the effort of the work to be done is obviously important, it impacts my customers business and their success (not to mention my costs). Getting effort estimation wrong results in costs overruns, but more importantly it results in team morale suffering due to stretched out timelines. Delays rob the team of that great feeling we all like when a task is completed, if nothing else, we feel a small measure of pride in the accomplishment. Delays raise additional administrative burdens, and generally make people feel frustrated (maybe the better word is annoyed), typically because a people will need to explain to their bosses, to the board, and to customers why something is going to take longer and cost more, an administrative burden in the truest sense that most would prefer to avoid.

We prefer to pay careful attention to estimating the scope and difficulty of work at the beginning of a project, and we have found a serious game called Planning Poker to be very helpful.

Thanks for reading David’s Substack! Subscribe for free to receive new posts and support my work.

Subscribed

Consider two behavioural problems that are very common in large and small organizations. First, the planning fallacy, a cognitive bias that leads individuals to underestimate the time, costs, and risks of future actions while overestimating the benefits. For instance, a product design initially estimated as a three months stretches to six months, doubling the time and resources initially anticipated, because the complexity of a key detail was not properly factored in to the plan. Planning Poker, helps avoid such miscalculations by sourcing better insights from the team the team to be tasked with implementation.

Second, HiPPO effects (Highest Paid Person's Opinion). These have been a frequent cause of product and project overruns and are more pronounced in hierarchical organizations and in cultures with a degree of high power-distance. HiPPO effects cause the opinions of higher-ranked individuals to overshadow those of the individuals on the team doing the work, leading to honest opinions of effort to be kept private. If I’m being honest here, these effects are most common when an engineer is not in the room, and when the product sponsor is present (especially when the project team is Asia-based.

We learned from experience many years ago that planning poker was a great solution for a team, especially when teams are made of people from multiple cultures (i.e., a Canadian, a Brazilian, a Thai, and an Indian form a new product team). After the team has been given a project, one of the first tasks is to lay out product requirements, features and user stories.

This is typically done on a white board, but can also happen in Jira, or other project management software. Once done, each team member is asked to write down a number which represents the difficulty or effort to complete that feature. The number should be written down by each member of the sprint privately, and without speaking. The number they write down can be anything, it can be 10 million or 5. The idea is to produce as unbiased an estimate of work as possible from each team participant, avoiding groupthink. Scores are then revealed simultaneously, ensuring that estimates are not influenced by peers or senior team members. This not only democratizes decision-making making people feel like their opinion is actually considered, it makes teams collective estimate more reliable.

This is a great way to pull deeper insights out of individuals that would normally be quiet, often this is the engineer, improving our understanding of each other, the work ahead, and the actual competencies of the team. I remember building a product onboarding feature for a health product, something we call a wizard pattern. The engineer assessed the task as a colossal challenge, rating it a million points in terms of effort. The database architecture needed for this feature was unfamiliar for him and he figured it would require him to learn a new programming language (R) to build it. Meanwhile, the product designer who had worked on this type of feature before thought the task to be relatively straightforward, assigning it 50 points. These differences were a great starting point for constructive dialogue, and led to a team building opportunity, a more accurate understanding of team competencies, and a plan to address the features build. The product designer and the front-end engineer offered to help with the coding of this features and brought down the effort considerably for the engineer. This is one of the most valuable aspects of Planning Poker, it helps build trust and transparency with new teams, exposing a greater diversity of opinions and capabilities and helping the product owner move things along much more quickly.

**Beyond Estimation: Paving the Way for better Prioritization**

Planning Poker is not just an array of task estimates, the estimates serve as foundational inputs for the prioritization exercises that follow. In large organizations, managing multiple products and change programs, Planning Poker provides a more effective and reliable estimate of effort enabling better prioritization of strategic objectives that maximize value and impact. This is why I use it as early as possible in any project, it helps me get to know the team, and provides a clearer assessment of the work to be done, which ultimately helps leadership make decisions more confidently and decisively.

‍