Do you practice the planning game?

Question

In our small development team we are adopting the agile way of developing our software. We try to stick to one month development cycles.

At the beginning we play what we call "the planning game". The idea is to filter out all the issues and find out the ones to be handled in the upcoming iteration. Here it is in a nutshell: every person (developer, user, analyst, etc.), involved in the project, is more or less aware of all the minor and major issues. Also, everybody has a more or less definitive wishlist of issues to be fixed in the upcoming iteration.

Everyone takes several small square pieces of paper (5 to 10) and writes down all the important (in his opinion) issues -- one issue per one piece. Now, all the pieces are stuck to a whiteboard, but not randomly. The left edge of the board is priority, while the bottom is complexity (like Y and X axes). All the papers are sorted out based on priority and complexity. Thus, a simple and not urgent ends up in the left bottom corner, moderate complexity / priority -- in the middle, and extremely complex but urgent in the right-top. Well, you get it...

After a bit of discussing and tossing the papers around we have all of them arranged properly on the whiteboard. Of course, we might get rid of some of the papers along the way, because we don't want to be overwhelmed.

Once we are done we do not remove the papers. On the contrary, we let them stay during the iteration. After issue is fixed we put a big cross on the corresponding piece of paper. Personally, I really enjoy this step ;)

Well, now the question: do you practice anything like that in your team? If you do, how effective do you find this approach, how much do you like it, have you met any problems with this?

P.S.

Yes, this is subjective, but I personally really enjoy this game and it seems to help a bit during planning and even development phase to stay concentrated on the issue. So, your answers are really appreciated.

Answer 1

I know of at least one company that does planning by running trough all the issues and for each issue have each developer place a card on the table with their estimation of the time it takes to complete on the table (face down). They then turn the cards around and the person responsible for the game asks the ones with the highest and lowest estimates why they choose those. After this discussion, they do the same again and then base their time estimates base on a consensus of the team.

The idea here is to let the client decide what should be done, but let the developers (or rather the team) decide how long it should take.

The recent they put the cards down is to force each individual to do his or her estimation of the task, and not just say the same as the rest of the team.

Personally? I think it is all a bunch of bullshit, since no plan has ever survived contact with the real world.

Answer 2

We are doing scrum. There you have a planning game in order to find out what you can achieve in certain timeframe. The work is done in sprint that is a 2-3 weeks timeframe. Stories (bugs, features, etc) are estimated by using a card deck with numbers 1,2,3,5,8,13,20,40. Every developers shows a card on every story. The sum of all of these numbers can later be calculated to estimate how much can be done in this timeframe. The stories are broken down into tasks und these are written on postits. The wall has columns. Left is planned, then started, on review, done. The most important story is on the top. Then you start by taken always task from the top assign your name and move it to started and so on.

Answer 3

In our case, the priorities are primarily set by our customers. The developers' role in planning is mainly to estimate the cost so that our customers can consider cost/benefit when prioritising their features.

We discuss the tasks for each iteration to catch dependencies etc, but a game like this is of little use to us (we don't get to set the priorities, and we have to provide estimates in real-world numbers (man days of effort) to allow our customers to understand the costs in a realistic, commercial sense.

Answer 4

I know this may be old-school, but... in a previous company which will remain unnamed, we were using Scrum. During the Scrum planning periods that worked well (destroyed by a later manager who decided that engineers worked better when told what to do when), we would all get together in a room, and make suggestions about the issues that needed to occur for the product. These went into a list of items on the backlog; at a later session (and after a bit of pruning of the list to remove redundant items), the team would get together with the list of items on the backlog and discuss what items to take on during the sprint. That's it. It was very freeform, and while there was good feelings between all members of the team, it worked remarkably well. Yes, we would use a whiteboard, and folks took notes, but there were no "games" particularly involved; just a bunch of engineers in a (very small) conference room, discussing the best way to solve problems.

Of course, the whole well-working system got completely hosed up by a subsequent manager with a massive napoleon complex; there's no better way to utterly destroy a good team of engineers than to begin treating them like 3-year-olds.

Answer 5

I have used the planning game before, specifically Mike Cohn's Planning Poker. It works a lot like @Norbert's description. I was part of "micro-team" (of 2 people). While I really liked the idea, I found that it didn't really work with such a small team and that it required similar levels of knowledge of the domain/environment to be really effective. That probably isn't a limiting factor in most cases, but it was in ours and hindered its effectiveness. The places where our estimated diverged the most were due almost solely to differences in developer experience, not different perspectives or misunderstanding of the details involved.

The most valuable part, I felt, was that it stimulated discussion of the particular issues around the development. Now that I'm essentially a solo developer or, at best, teamed with a junior developer (sometimes a student), I've abandoned the game aspect and focused on the understanding portion. My efforts are spent trying to understand what are the most important features for the customer and what are they really trying to achieve rather than focusing on estimates of complexity. The tack that I try to take with regard to complexity is to keep my stories within the same order of magnitude. If I were playing the game and found a story that is above a 10, I'd try to break it down into smaller stories that fall below 10. This is really more of an automatic behavior -- I'll just say "that's really big, how about if we do these 2 or 3 stories..." I don't really think about it more than have a feeling about how I've characterized stories in the past.

The other thing that I do is try to group stories into logical, deliverable units of functionality that can be completed in about 2 weeks. That's really more of a planning tool as I tend to deliver functionality into QA as it's developed (1-2 day intervals) and into production as the customer feels it's warranted -- anywhere from 1 day to a month. Typically I do this in a wiki as my customers aren't co-located.

Answer 6

What you describe differs from the Planning Game we've done in XP shops and the Sprint Planning meetings we do with Scrum. In XP and Scrum, there's a single role (the "Product Owner") responsible for prioritizing the work that the team will take on for the next iteration. Suggesting things to the product owner is fair game, but they have the final say on priorities.

The development team, however, has the final say on estimating the size of the work that the product owner would like done. (Planning Poker, mentioned in another comment, is useful technique for helping the team converge on size estimates). The standard practice with both XP and Scrum is to only commit to completing no more (in total work size) than the team completed during the last iteration/sprint (i.e, the team's "velocity"). Think of this as "evidence-based scheduling".

With one set of interests (represented by the product owner) responsible for priorities, and another set of interests (the development team's) responsible for estimates, there's a nice balance that traditional software development often, sadly, lacks.

If part of what you're doing by having developers contribute to priorities is ensuring adequate time to address technical issues, an alternate approach, favored by XP, is include "cleanup" (refactoring) time in the size estimate for a piece of work. That is, the estimate includes not only the time to cook a meal, but also the time to clean up the kitchen (code) afterwords.

You don't mention estimation. If you're not doing that as part of your planning game, I highly recommend Mike Cohn's "Agile Estimating and Planning". It's a fairly quick read, and will give you lots of candidate ideas for improving your current process.

Answer 7

We definitively use it.

On our iteration planning meeting, we take all the previously prioritized backlog items and we make a "planning poker" session for each item, each member "vote" how much story points for each item.

We found out that even non programmers can help us is the planning game. Our IT manager and out business stakeholder has all the background history of our team and the changes made to our software, so they "statistic" know-how often leads the very accurate estimates.

Since every programmer actually participate in this process, they are very committed to the established time frames. They often fell guilt when they are unable to deliver all the stories in schedule. It really put some healthy pressure on everyone because everyone participated in the estimate. It's a very different from the PMP-like guys that create all the estimates without consulting the technical staff, were they don't fell guilt to not follow a deadline they didn't participated in the creation process.

The problem that sometimes the team actually discover that some stories are more complicated then they have anticipated. Perhaps a more "complex" estimation technique would be more precise in some complicated stories. Also, this technique is good for short-term estimations, but does not work at all for long-term estimation (I know all long-term estimation are evil, but sometimes you need just to get an idea of the effort, schedule and cost).

Despite this issues, I think this technique as a is overall improvement over the standard techniques.