Getting Started with Agile: Playing 'Poker' To Plan Agile Projects
That's exactly what Scotland's University of St. Andrews development team did...
- By David Ramel
- September 10, 2010
A two-day stint of playing "planning poker" was instrumental in helping a university Web team estimate the complexity of scheduled development projects, Gareth J M Saunders said yesterday in a blog documenting the team's conversion to Agile development.
"It was a really useful exercise," said Saunders, assistant information architect/Web manager at Scotland's University of St. Andrews, in his blog series titled "Our Journey into Agile." The posting was the second of a three-part series of blogs, which started two weeks ago when Saunders explained how the university Web team last year was inundated with a backlog of more than 120 projects that would take an estimated 13 years to complete, prompting the conversion to Agile.
"Something had to change," Saunders said. "We had to change. We needed to stop saying yes to everyone about everything and we needed to find a way to more efficiently and effectively plan and manage our projects. That's when we turned to Agile for assistance."
Planning poker, according to Wikipedia, "is a consensus-based technique for estimating, mostly used to estimate effort or relative size of tasks in software development."
Yesterday Saunders explained how the team created home-made cards for the planning poker game it used to come to a consensus about the size or difficulty of the projects on its development plate.
According to Saunders, his team sat at a table last November and addressed the list of projects, which were explained to the team by whoever who was most familiar with each project. After the briefing, each team member secretly chose a card with varying numbers corresponding to his estimation of the project's complexity. He said the cards were loosely based on the Fibonacci series. "Our cards used 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? and Break," he said (the "break" card indicated the team member wanted to take a break). The cards can be seen online here.
Team members flipped their cards over simultaneously, Saunders said, and he then asked those who provided the lowest and highest numbers to explain their rating, with the aim of reaching a team consensus on the relative difficulty of the project through discussion. After this discussion, repeated votes were taken until an agreement was reached. Saunders didn't specify the number of members on his team, but a university Web site indicates it includes four people.
"By the end of the two days we still had a list of 120+ projects but each project now had a value indicating how difficult or complicated we reckoned each one was," Saunders said.
The projects were then presented to the boss, who prioritized them according to various factors. That resulted in some 20 projects being canceled or postponed. Saunders said the team then had to break that news to project stakeholders. "Most people, to be honest, were very understanding," he said.
Saunders explained more about planning poker in his personal blog last April. There he explained that the Web team didn't try to convert totally to Agile development practices all at once. Instead, like many other organizations, it started off with certain aspects of the Agile process, such as version control, stand-up meetings and a product backlog. That blog also features a photo of team's "Agile/Scrum iteration planning board," for a visual representation of its planning process.
The final blog post in his current series, Saunders said, will detail how the team addressed the project list and what Agile tools it's using.
A free online version of planning poker is offered by Mountain Goat Software.
David Ramel is an editor and writer for Converge360.