Few executives would be happy to walk into their conference rooms to find their leading staff playing poker but in software companies, that’s exactly what’s happening. And the boss is playing as well. The players aren’t gambling with their salaries though, or even their options. They’re betting on the amount of time it will take to develop a feature. The practice is known as Planning Poker and it’s become the leading productivity technique for companies using agile development, a way of planning software in limited time using cross-functional teams and flexible responses.
The method was first developed in 2002 but was popularized by Mike Cohn, a consultant whose company Mountain Goat Software later trademarked the practice. The aim is to bring focus to planning meetings and to produce accurate estimates of the amount of time required to complete a development process.
Each participant, or “estimator,” holds a deck of Planning Poker cards. The values shown on those cards can vary. Mountain Goat’s cards show 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 and 100, with a question mark and an infinity symbol rounding out the series. Other cards use a standard playing deck, with the King suggesting that an estimate is impossible to provide, and even the Fibonacci Sequence with the growing gaps between the figures reflecting the difficulty of estimating large numbers.
Depending on the discussion, the values may represent the number of development days required, “story points” (or features), or any other unit the team wants to use.
The team members discuss the feature to be added, then choose a card that represents, usually, the amount of time they think the feature will take to develop. If all participants agree, that time becomes the deadline and the team is ready to move on to the next stage. If there’s disagreement, the discussion continues with the players of the highest and lowest cards in particular required to justify their choices. The process is repeated either until consensus has been reached or until the players agree to defer the decision until they can learn more about the “story point’s” requirements.
The aim of the process is to avoid discussions being anchored by early estimates. Without using hidden cards, discussion can take place around the first estimate offered by one of the participants instead of each member providing their own insight.
From Poker To Scrums
It seems to work. A 2007 study which applied Poker Planning to half the tasks in a software project produced group consensus estimates that were “less optimistic than the mechanical combination of individual estimates for the same tasks.” They were also more accurate.
The reason for that accuracy, say some experts, is that it allows the people most competent to solve the task to estimate it. Being required by peers to justify choices also improves accuracy, especially for tasks whose requirements aren’t entirely clear.
With consensus reached and the game over, the process then moves into the next stage. Users of Poker Planning tend to combine it with Scrum, a form of team-based sprint planning.
The teams are self-organizing and cross-functional with no leader who assigns roles. Instead, the team as a whole decides which members will be responsible for which tasks. Those team members are joined by the Product Owner (or “PO”) and the “ScrumMaster” who works as the team coach.
Scrum requires projects to progress through a series of sprints that usually last two weeks but should last no longer than a month. At the beginning of the sprint, a planning meeting is held at which the members commit to a set number of items and create a “sprint backlog,” a list of tasks they need to perform. As the sprint progresses, the feature should be coded, tested and integrated into the product.
Each day, the team meets for fifteen minutes. Led by the ScrumMaster, the members discuss the previous day’s work, explain what they’ll be doing that day and identify any problems they expect to encounter. Those daily “scrums” are intended to synchronize the work of the team members during the sprint. Finally, when the sprint ends, the team holds a “sprint review” to demonstrate the new function to the PO, and the team moves on to the next sprint.
Planning Poker and Scrum meetings have the advantage of being simple and easy to understand. They’re also quick. The inspiration for Planning Poker was a meeting at a software firm in which two staff members debated a time estimate while everyone else in the room drifted off. By the time the meeting ended only two people had been heard and the estimate was the same as the one they’d started with. Planning Poker forces everyone to take part and the meetings are limited in time.
Win At Online Poker
They can also be held by different kinds of companies. Mountain Goat Software has developed PlanningPoker.com as a kind of digital meeting room that can be used by distributed teams, enabling even freelancers and virtual workers to take part in discussions.
One question though is whether Planning Poker and Scrum meetings can be extended beyond software firms. While programmers are likely to work together, with different specialists responsible for back-end, front-end, database and UI development, designers are more likely to work alone or to form part of a product team. Writers may find themselves working alongside researchers but those projects tend to be more straightforward with clearer tasks, responsibilities and milestones than those used in software development.
The meetings themselves can also take time and that time may not always be well-spent. The goal of a Planning Poker meeting is consensus, but when consensus is reached in a meeting, it’s often because the boss has imposed an idea that other team members have agreed to follow. A Planning Poker meeting that doesn’t end in an agreed time estimate will either result in a postponement of the project or a deadline that could have been imposed without such a meeting.
Nonetheless, Planning Poker and Scrums have managed to push out other forms of agile development. Don’t be surprised next time you win a freelance programming job, to be invited to play poker.
Recent Comments