Name Iteration Planning Type

Download 28.12 Kb.
Date conversion14.11.2016
Size28.12 Kb.

MobileD/All phases/Planning Day/Iteration planning process

Pekka Kyllönen, Juha Koskela



Iteration Planning


Pattern type:

 Phase pattern

 Stage pattern

 Task pattern

Pattern classification:






The purpose of this task is to generate the schedule and contents for the iteration to execute. The contents are defined in terms of tasks which are work orders for the team.


The goal of the iteration planning is to:

  1. Transform stories into a set of unambiguous and well defined tasks.

  2. Generate design drafts to support estimation.

  3. Estimate the effort required to perform tasks accurately.

  4. Establish a dependable schedule for execution.

  5. Attain consensus on iteration target with the project stakeholders.


Entry criteria:

  1. Requirements analysis task is performed so that stories can be attained.

  2. Acceptance test results are available from previous complete iteration.


  1. Product backlog prioritized according to customer expectations.

  2. Metrics data from previous iteration(s) to determine team velocity.

  3. Metrics data from previous iteration(s) to adapt with estimation errors.

  4. Acceptance test documentation to issue bug fixes and enhancements.


Exit criteria:

  1. Most valuable stories are discussed and transformed to tasks defined to such an extent that they can be implemented and verified.

  2. Acceptance test criteria is approved by the customer and recorded.

  3. Iteration schedule is discussed and consensus on contents is attained.

  4. Sum of estimated efforts doesn’t exceed the adjusted velocity.


  1. List of selected stories and tasks to be performed.

  2. Development artefacts generated to support estimation and communication.


The following picture illustrates the iteration planning process work flow.


The individual components (e.g. the steps of a task pattern) illustrated in the previous process figure are described in detail.

  1. Collect and discuss release test reports. The results of the previous release tests are processed and the correction actions are identified.

  2. Select and prioritize new story to implement. The new stories identified in the requirements analysis task are selected based on customer value.

  3. Determine team velocity. Team velocity of previous iterations is evaluated and new velocity for forthcoming iteration is decided. The team velocity acts as a measure for how much tasks can be issued.

  4. Transform release test issues and new stories to tasks. Test issues identified in step 1 and stories selected in step 2 are processed into tasks. Priority should be given to defects and enhancements.

  5. Refine tasks with design drafts. Tasks identified in step 4 should be refined with design drafts such as user interface and sequence diagrams and other necessary means until an objective estimation can be proposed. Drafts should be validated with the team and customer whenever possible. However, more technical details should be omitted from the customer.

  6. Estimate task efforts. The estimations for tasks are recorded and summed to iteration contents. Customer can reorder stories if selected stories are found too expensive to produce.
    ** Iterate to step 4 until team velocity is spent. **

  7. Establish iteration schedule. Task priority and precedence should be discussed. Iteration contents should be discussed with the team and other stakeholder to attain consensus.


The document templates and tools that can be utilized to facilitate the conducting of the pattern are listed and defined here.


  1. Story cards, task cards for writing down stories and analyzing tasks.

  2. Test plan templates for recording acceptance criteria for stories.


  1. Pen and paper for enabling agile design and drafting.

  2. Tracking or recording tool for tasks if applicable.

  3. Information radiator for project status controlling.


The roles that can be identified in executing the pattern are listed and defined here.

  1. Customer prioritizes stories and fixes/enhancements.

  2. Project team/Tester records acceptance test criteria, approves with customer.

  3. Project team/Metrics collector analyses metrics for possible adaptation actions.

  4. Project team/Project members transform stories into tasks and estimate them.

  5. Project team/Project manager assures that the task is performed efficiently.


The answers to the frequently asked questions will provide additional in-depth information for conducting the pattern. The information presented has been gained when applying the pattern in practice.

  • Isn’t requirement prioritizing a task of the requirement analysis phase?
  • Yes, but often the knowledge gained about the feature’s implementation possibilities during the planning session can have effect on the original prioritization of features. If the cost of some feature gets too high, the customer might prefer to have some other features built instead.

  • Isn’t feature breakdown to tasks actually a design activity? Why is it performed during planning? Should the customer be present?

  • It is very difficult if not impossible to estimate all the work needed to be done to implement a feature using the non-technical description of the user stories. The nature of the tasks is more technical and therefore the need for customer presence is debatable. The purpose of task definition is that each task should be refined until the required work can be estimated beforehand and verified afterwards. The extent to which to refine is naturally subjective and exploiting expert opinion whenever possible is advised. Plus, you get some design drafts which you later can use as documentation into the bargain.

  • What is the recommended size of each task? What do we gain using such a granularity?

  • As a rule of thumb, make an attempt to aim at 4 hours work per task. Lower or higher is OK when necessary. Task defined is such exactness can be verified reliably, which enables precise measurement of progress. Note though that the length of the planned iteration may have an effect on the desired task size. For an iteration of two weeks we have found 4 hours to be suitable.

  • Why don’t we plan for other tasks such as the planning itself or the release activities? Explain the velocity.
  • To simplify the planning and estimation, we have adopted the term velocity in a similar sense it is used in Extreme Programming. In a nutshell this means that we should plan only for work that will provide to the project, with velocity being the measure for actual programming effort, other activities such as documentation can be done on the other part of time and of course, when such activities provide for the project they can be tasked. For an example of velocity, a four-member team on a two-week iteration, with velocity of 50%, there would be (4prs * 10 days * 8h/day = 320h, velocity 50% = 160h) a total of 40 tasks each averaging 4 hours of work.



Other patterns which are part of, composed of or associated closely to the pattern are identified here.

  • Requirements analysis task provides the inputs for this task and is therefore important to be executed carefully.


Possible variations of the pattern are presented here together with additional information of their applicability.

  • Different life cycle phases have different focus. For example, the first iterations should consider building and planning the architecture so that the later phases can build on it. Also, later phases such as stabilize focus on improving existing functionality and removing defects instead of implementing new features till the end of the project.

  • The presence of on-site customer helps the requirements analysis and planning phases. This can enable a more efficient planning session and the features or tasks can be left less refined as the on-site customer can be used to validate them.

Possible risks which can result from applying the pattern as well as the solutions including pre-emptive actions for avoiding the risks and actions to take to minimize their effects are discussed here.


Further Reading

Extreme Programming includes Planning Game as a one key practice, for more information see e.g. [1, 2].

[1] K. Beck, Extreme Programming Explained: Embrace Change: Addison-Wesley, 1999.

[2] K. Beck and M. Fowler, Planning extreme programming. New York: Addison-Wesley, 2001.

The database is protected by copyright © 2017
send message

    Main page