Iteration Planning: an example

How long does it take the planning meeting?

task board.jpg
Logan Ingalls – Task board. Licensed under CC BY 2.0 via Wikimedia Commons.

Usually 1/2 day to 1 day max, depending on the iteration size.

The first part can be used to review, clarify and select items from the product backlog and to set a goal together with the product owner (PO) for this iteration.
The team and the product owner must attend, anyone else can but non necessarily: for example, customers or the management can be part of it.

The second part is for the team (the product owner is not necessary anymore but can remain if wished), to define how to build the selected functionalities. Here the team members sign up for tasks and estimate them.
Keep the tasks short, in case break them down. My suggestion is to have 1-8 hours tasks, so that every day you could have something complete, this has really a positive psychological effect. Smaller tasks are also easier to estimate.

Usually these kind of meetings drag on so it’s up to the product owner or the project manager to avoid too long discussions and in case to cut short the meeting when the ends approach: extending the meeting usually does not help (people are too tired) and would anyway be against the principle of time-boxed activities; acceptable could be to set a continuing session on the next day but this would take away time from the iteration.
So, the best compromise is to stop and let the iteration suffers: it will be a valuable lesson for the team, for the next time.

Assuming that the product backlog is ready, and the timeframe is defined you can follow this script:

  1. clarify some “administrative” points: when you start the iteration, when will be the end and when will be the demo date, what is the availability of the team members (holidays, trainings, etc.)
  2. define the iteration goal and give a short summary (by the PO, max 30 minutes).
    Coming out with a sprint goal can be difficult but it is worth to spend some time thinking about it: just define it in business terms and not technical terms. This means that people outside the team will understand it when they read it. Usually the PO should come out with the goal, the title of the sprint, (he should think about it in advance and come to the meeting with it ready) and is just the answer to the question why are we doing this iteration? And of course must be something incremental for the product.
  3. based on the goal, the team does a first selection of items from the product backlog that can be achieved in the timeframe (upon the draft estimates from the product backlog and the team availability); the team can follow the backlog priorities (so we are sure that we are building the right things) but can swap some of them or add tasks if they are needed for design or architecture congruence. This is an initial selection, the items can be further adjusted during the meeting.
  4. the product owner clarifies each backlog item and the how-to-demo part whenever is needed.
  5. the team breaks down the items into tasks. Improve the estimates. You can use some tool when you do that, so you know item after item what is the current work planned and how much time is left. For example, just a simple spreadsheet, where the estimations are recorded, summed and how much space is remaining is shown real-time. In this way you can have a reality check, and you will know when you have enough tasks for the iteration.

One thought on “Iteration Planning: an example

  1. Pingback: The iteration backlog and the definition of done | Look back in respect

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s