Planning Poker with Undergraduates

I have spent many hours working on the product backlog for Fall's Game Programming (CS315) class, in which the students will implement the Morgan's Raid game. Originally, I specified the story points for every user story, but I was concerned that my estimates were not representative, especially since my teams were comprised entirely of novices who are familiar with neither the technology nor architecture.  Following the advice in Clinton Keith's Agile Game Development with Scrum, I decided that a planning poker session could be the best approach for reliably determining story points. Briefly, in a planning poker session, each participant has a hand of cards, and each card has a number on it. For every user story, the participants choose and then simultaneously reveal the number of story points they chose, repeating until consensus is reached. This facilitates communication among stakeholders about the product backlog.

My backlog currently has about 70 user stories, about 25 of which are high priority. An ideal planning poker session would contain stakeholders with areas of expertise relevant to the project. When dealing with undergraduates, there are no experts, but the gulf between novice and expert itself provides a motivation for planning poker. Although I work with undergraduates regularly, I still find that I often make mistakes when estimating how long various tasks will take them, especially when integrating ideas that I have internalized but that are new to them. In a project involving a combination of object-oriented and entity-oriented design, Scrum, continuous integration, and unit testing --- all of which are new to the students --- there are ample opportunities for estimation errors! A planning poker session, I figured, could help us determine more accurate story points than if I did it myself. This would also be an excuse to explain the various parts of the experience to a subset of Fall's class, giving me practice and seeding the class with students who have already seen some of the ideas.

(A parenthetical story: Last night, my wife asked me about this morning's meeting, and I told her briefly what it was about. My brief explanation was completely insufficient, so I explained to her some principles of agile software development, Scrum, continuous integration, and planning poker. It seems that, despite the effort I have invested in preparing for the course, I only ever really explained it to her as "working on my spreadsheets." Explaining all of these things to her --- who has as much experience with these ideas as many of my students --- was a great experience for me. This also means that she probably doesn't read my blog, so I can safely write about her here, as long as we all keep our mouths shut.)

I sent out an invitation to some of the students I know who are signed up for CS315, using Doodle to find the time that most could meet. I wish I could have had them all, since I chose them for their breadth of experience and perspective, but the best I could do was Tuesday morning with four of the invited. This morning, one informed me he could not attend, and another did not show, so the meeting went forward with me and the two students. Not counting coffee and bagel time, we worked for about 90 minutes on the backlog and covered all the high priority items. I don't know anything about the programming skills of these two students, but I will say that if I have a class full of students as clever and motivated as them, this semester will be fantastic. As one might expect, the first few were a little rocky as I had to explain some of the background and we had to get a feel for the abstract measurement of story points. We quickly hit stride, and the story point negotiation revealed places where more detail or more stories were needed.

It so happens that all three of us at the meeting are gamers, and it was interesting to engage in planning poker as a cooperative game, especially given my recent interest and readings on software development as a cooperative game. Having this meeting face-to-face, it was fun to choose point values and hold the card face-down while waiting for the others to choose a value: there was the tension of anticipation, the climax of revealing values, and verbal and non-verbal negotiation, and the joy of consensus. In fact, in the few cases where we all chose the same value the first time, it definitely felt like a "win." The experience was a game in Huizinga's sense, especially in the construction of a time-boxed community of players in a shared experience. Qualitative technical communication researchers, take note for potential future research opportunities!

I am confident that the values we determined are reasonable and will give realistic measurements of teams' velocity. Based on this positive experience, I plan to have another planning poker meeting with some volunteers once we make progress on the high-priority user stories. I hope that the experience was as enjoyable for the students as it was for me. My only regret is that I did not take a picture of my awesome planning poker cards before I left, but they are in my filing cabinet for another day. Now if that's not reason enough to come back for more blog, I don't know what is.