Home > Developers > Wiki > Planning Poker
Views


1   What is Planning Poker?

Planning poker is an agile solution to the complex problem of helping engineering teams quickly perform high-quality estimates. Planningpoker.com has a more complete, more detailed explanation of planning poker, as well as excellent additional resources on planning poker should you want to explore the topic deeper.

1.1   Meeting Times

A public calendar with Planning Poker meeting times is available in HTML (US/Pacific time) , iCalendar, and XML (atom).

Webcal link.

Mac OS X and Ubuntu users: try clicking on the webcal link above.

Outlook users: here and here are some general instructions for adding internet calenendars with Outlook 2007. Outlook 2003 users, please try the RemoteCalendars plugin.

Another option to sync with Outlook is Google Calendar Sync.

1.1.1   Strike Teams

The Mifos team recently favors ad-hoc 2- to 3-person "estimation strike teams". If more than a small handful of stories need estimation when the next scheduled planning poker session occurs, said planning poker meeting will be held as planned.

2   Mifos Development Estimation

The Mifos software engineering team uses planning poker as a means of estimating User Stories prior to initiating development.

Please also feel free to observe planning poker in action on the Mifos IRC channel. Meeting announcements are sent periodically on the mifos-developer mailing list. There is also a teleconference; Please ping Adam Monsen for more information.

2.1   Why IRC?

IRC is used to make it easier for the general public (those without voice during the meeting) to observe and interact when necessary. Since the code is all FLOSS, we like to keep development as transparent as possible. The meeting is conducted over Skype (voice) and IRC (text chat) simultaneously; IRC is key for the "poker" part of "planning poker".

3   Approaching Accurate Estimates

3.1   The number

Estimating stories is tricky. No one person knows every detail about Mifos; group wisdom is what we're trying to bring out. There is always some degree of learning, teaching, and training that occurs in planning poker meetings. So don't worry if you don't know "the real number". We'll figure it out together!

3.1.1   Possible estimates

Why the strange sequence of possible estimation numbers (1,2,3,5,8,13,20,40)?

  • estimates for larger stories are less accurate
  • encourages breaking down stories into manageable chunks

3.1.2   Reasonable estimates

So you know how complex a story is, but what's a "one point story"? What's an "eight point story"? This really depends on who is doing the estimating. The estimates are roughly averaged across the group since everyone participates, and a "calibration" will emerge over time.

3.2   Calibrated Results

This section will eventually contain stories that exemplify our group's calibrated story estimation values. Usually a story greater than 5 should be broken down into smaller stories if possible since stories with point values greater than 5 usually have more complexity than can be addressed in a single iteration.

3.2.1   Typical one point stories

  • #176 - "Review patches for issues 1481, 1502". Repro is straightforward. Patch is small in size.
  • #279 - " As a Mifos specialist I want to know how to change configurable Mifos properties so Mifos will work like I want it to". Documentation only.

3.2.2   Typical two point stories

  • #182 - "Mifos Deployment on Tomcat 6.0". Roughly double the complexity of a typical one-point story.

3.2.3   Typical three point stories

  • #284 - "Issue 1549 - Redo Loan disbursal does not allow loan to be redone for dates in the past". Apparent complexity in loan data flow. May affect unit tests, may require database work.

3.2.4   Typical five point stories

  • #175 - "generalizing MySQL specific SQL in java code". Good size chunk of complexity. Potentially touches many areas of the application and requires a significant amount of refactoring.

3.3   About time

How does the point value equate to time a developer will need to spend implementing a story? Best not to worry about this. It will taken care of later on during the planning process. One story point is roughly equal to one developer day, but this isn't a hard and fast rule.

4   Meeting Organizer Guide

4.1   Script for Running the Meeting

The following information is cut and pasted into the chat channel by the meeting organizer to initiate and focus the planning poker meeting:

  • Setting up for planning poker. Please dial in.
  • Participants/observers, for more info on IRC, see: http://mifos.org/developers/technical-orientation/irc-mifos/
  • Note to observers: sorry, not all information will be shareable. The people with voice in this channel are on a voice call.
  • possible estimates: 0.5,1,2,3,5,8,13,20,40
  • Story points do not necessarily equate to time required to implement stories. Rather, the story point value should indicate the story complexity relative to other stories.
  • List of stories to estimate: {STORY_LIST}
  • while estimating a story...
    • Story {STORY_NUMBER} - {DESCRIPTION}
    • {LINK(S)}
    • ready, DEAL.
    • ready, RE-DEAL.
    • agreed on {ESTIMATE_VALUE}.
  • That's the end of today's planning poker. Thank you for playing!

4.2   Followup Procedure

4.2.1   Audit Trail

After the meeting, the organizer records changes to Story Cards in Mingle to the following fields:

  • Comments - add important points from dev discussion on IRC
  • if story was estimated...
    • Planning Estimate - enter agreed-upon value
    • Status - set to "Ready for Development"
    • Comments - add implementation notes, gotchas, etc.
  • if story could not be estimated...
    • Status - set to something other than "Ready for Estimation"
    • Comments - add details why story could not be estimated

4.2.2   Transcript

The meeting organizer is also responsible for sending out notes to participants. The IRC log transcript serves this purpose.


Grameen logo