An Agile Exercise

I am a member of the Agile-RTP group which meets monthly to share knowledge on agile development. This month we had a "fishbowl" event where Ken Auer of Role Model Software would grab some members of the audience to be a development team and hold a compressed planning session to capture and estimate a project to develop an application. I played the role of the customer and provided the problem. I asked another member of the audience (Glenn Watson) to join me and also play the role of customer.
I used a real project that the team I managed at IBM had completed for Kraft Foods. Kraft was building a kitchen of the future at their Chicago headquarters to showcase concepts of how meals would be prepared someday. They had a concept video of some of the functionality that they wanted. I showed part of this video to the group at the meeting and then Ken grabbed some index cards and asked Glenn and I what functionality we wanted in the system. We used the classic User Story format (As a I want the system to , so ). Here are some examples:

As a family member, I want the system to capture my food preferences so it can assist with meal planning.
As a family member, I want the system to capture my weekly meal plan, so it can provide a meal suggestion.
As a family member, I want the system to alert me when the meal plan violates my nutritional goals.
As a cook, I want the system to provide a recipe adjusted by my nutritional goals that I can follow, so I will be able to prepare meals more effectively.

We ended up with a dozen cards or so.
Then Ken asked the developers for each card if they thought that card could be implemented within one month. This filter was used to find epic stories that might need to be re factored.
I think that a couple cards were separated into a basic and refined version. And one card (getting recipe info from an XML source) was set aside as possibly not requiring a separate development effort. Ken also suggested that we might want to develop a basic screen navigation flow.
So I think that this left us with thirteen cards.
Now Ken asked each of the developers to vote on if a particular card would take 1,2,3,or4 weeks to complete. If there were a wide discrepancy in opinion, discussion was encouraged and then a consensus was captured on the card.
Now came the magic...

Ken said that in his experience with different team sizes he had determined a rule of thumb for productivity. He had different ranges for different team sizes up to a max of twelve members. For this project the team size was four and the range was 8-12 points per month. Since this team had never worked together before he recommended we stay closer to 8.
Glenn and I then were asked to group cards together into sets of functions we wanted developed in one month sprints with the sum of values on the cards to be approximately 8.
My logic in grouping the cards was to get functionality associated with initial setup, weekly planning, and meal preparation into separate piles and implemented in that order. Turned out with the budget we had resulted in five columns of cards. So this was a five month x four person release plan.
At this point in the meeting we had a lot of Q&A. A lot of discussion over how arbitrary the points process was. Glenn pointed out from his experience at Siemens where they had a dozen teams working agile they let teams calibrate points within the team so that trying to compare velocities between teams was impossible.
I pointed out that this had been a real project and when the dust had settled it had taken a team of 3 developers four months to get the system ready for the Kraft Kitchen of the Future. The team used Java and had some pre-existing frameworks that used the OSGi architecture to implement the embedded aspects of the solution.