Iteration Planning Meeting

developers and customers meet in a nice big room stories for the iteration are determined by ReleasePlanning customers typically read all of the stories for the iteration aloud - this gives everyone a common context re: what we're doing this iteration next:

 IterationMeetingFor?(someStories){
   for(eachStory){
     Developers.gainUnderstandingOf( eachStory )
   }

   unplannedStoriesIterator = someStories.getIterator
   while(unplannedStoriesIterator.hasNext)
     GenerateTasks?( unplannedStoriesIterator.next )
 }

 Developers.gainUnderstandingOf( aStory ){
   Customer.read( aStory)

   while(Developers.cannotDefineTasksFor( aStory ))
     Customer.explain( aStory )
 }

The overall structure is that the Customers explain the Stories to the Developers who ask questions until the Developers feel like they can define tasks for the stories. The process of generating tasks for the stories may result in the stories being changed as shown below:

 GenerateTasks?(someStory){
   Developers.generateTasks( someStory )

   for(eachTask){
     Developers.commitToTask( eachTask )
     if(theTasks.committedTime > Iteration.timeAvailable)
       Customers.reduceScope( someStories )
   }
 }

Developers try to figure out the tasks they need to accomplish in order to implement the stories. Once all the stories have tasks (are designed) Developers start writing their names next to tasks, estimating how long development will take as they go (estimates are in IdealProgrammingTime) developers sign up for as much work as they can do in an iteration. If the developers run out of time before they run out of tasks then the Customer must reduce scope - splitting stories, defering them entirely ... how they do this is up to them.

 Developers.generateTasks(aStory){
   while(aStory.needsMoreTasks){
     while(Developers.cannotAddTaskFor( aStory ))
       Customers.explain( aStory )

     Developers.addTask()
     if(Customer.wantsToChangeScope( aStory))
       return Developers.generateTasks( Customer.changeScope( aStory ) )
   }
   return tasksForStory
 }

Developers generate tasks by trying to figure out how to implement the Story and breaking that implementation into testable pieces. The Customer observes this process and may decide to further explain the story or even change its scope. This results in the Developers making the appropriate adjustments to their list of tasks for the story.

 Customers.reduceScope( someStories ){
   sort( someStories, byPriority, lowestPriorityFirst)

   for( eachStory ){
     reduceOrEliminate( eachStory )
     if( Developers.removeUnneededTasksFor( eachStory) == removedCommittedTasks )
       return theAlteredSetOfStories
     else
       if(theTasks.committedTime <= Iteration.timeAvailable)
     return noStoriesLeftToEstimate
   }
 }

The customer starts to look at the tasks and the stories - they have to figure out if they want to remove stories or redefine stories so that the Developers can remove tasks from the iteration. This must continue until Developers are shifted off of a "deleted" task resulting in their having time that they can commit to remaining tasks, or there are no uncommitted tasks left.

 assert(joeReader.understandsThisPage());//this assertion is meant to check this pseudo-code style of wiki page

Pair written by JoshMacKenzie and PhilGoodwin

---

does this assertion pass? ---

Yes for me. Thanks Phil - its nicely done (in a geeky way) - DuncanMcGregor

Thanks, Duncan. It was fun working with you.