Iteration plan
The iteration plan plans out a specific iteration in more detail, so the planning horizon is a single iteration. This is typically 1–4 weeks in duration. This is the last chance to adjust the expectations of the iteration before work begins.
Purpose
The purpose of the iteration plan is to ensure that the work allocated to the iteration is achievable, decompose the larger-scale work items (for example, use cases and technical work items) into smaller work items, and plan for the completion of the iteration.
Inputs and preconditions
Preconditions include the release plan and the initial iteration backlog.
Outputs and postconditions
The resulting plan includes the complete work items, generated engineering work products, identified defects and technical work items (pushed into the product backlog), and uncompleted work items (also pushed back onto the product backlog).
How to do it
Use cases in the iteration backlog, which may take an entire iteration to fully realize, are decomposed into user stories or scenarios, each of which takes a few hours to a few days to realize. The iteration plan is created just-in-time before the start of the iteration but is based on the release plan. This flow is shown in Figure 1.23:
Figure 1.23: Iteration planning
Review/update the iteration mission
The iteration should already have a mission from the release plan. This will include:
- Functionality to be achieved (in use cases, user stories, and/or scenarios)
- Target platforms to be supported
- Architectural and other technical work items to support the functionality and technical epics
- Defects identified in previous iterations
- Spikes to reduce risks
There is a decent chance that this mission will require updating, based on lessons learned in preceding iterations, so this is a place to do that if it has not already been done. Any changes made here may impact the allocation of work items to the iteration backlog.
Select work items from the backlog
Based on the iteration mission, the list of work items allocated is reviewed. Some may be removed or new ones added, as necessary and appropriate.
Break use cases into user scenarios or user stories
Use cases themselves are generally rather large and it is useful to have smaller work items in the backlog. These work items might be estimated to take anywhere from a few hours to a few days. Note that estimation of epics and use cases is often done using relative measures (e.g., use case points) but once you get down a few hours in duration, estimates often transition to hour-based, as determined by the team’s velocity.
Break use stories into tasks
If the user stories are small, then this step can be skipped. If they are still rather large, say a week or two, then they might be decomposed further into smaller tasks. This step is optional.
Estimate the effort for work tasks
If you’ve decomposed the original iteration backlog work items, then those elements should be estimated. This can be done either using relative measures, such as story points, or absolute measures, such as the number of hours to complete.
Put tasks into the iteration backlog
Any modified or newly created work item tasks must be added to the backlog for the iteration.
Evaluation team loading
Once we have a detailed vision of the expected work to do in the upcoming iteration and a pretty good idea of the effort, we can reevaluate whether the scope of work is reasonable.
Adjust team
The size or makeup of the team may be adjusted to better fit the more detailed understanding of the scope of work to be undertaken.
Adjust backlog
If the scope looks too demanding for the team, items can be removed from the iteration backlog and pushed back to the product backlog. This will spin off an effort later to rebalance the release plan. Note that this is also done at the end of the iteration, when the team can see what planned work was not achieved.
Iteration planning is pretty simple as long as you keep some guidelines in place. The larger-scale work items allocated to the iteration are sized to fit into a single iteration. However, they are decomposed into somewhat smaller pieces, each taking from a few hours to a few days to complete. For use cases, this will be either user stories or scenarios; this decomposition and analysis will be detailed in the recipes of the next chapter. The work items should all fit within the mission statement for the iteration, as discussed in the first recipe, Managing your backlog.
The work items should all contribute to the mission of the iteration. If not, they should either be pushed back to the product backlog or the iteration mission should be expanded to include them. It is also helpful to have the larger-scale work items broken down into relatively small pieces; you should be less concerned about whether are called use cases, user stories, scenarios, or tasks, and more concerned that they 1) contribute to the desired functionality, and 2) are in the right effort scope (a few hours to a few days). Work items that are too large are difficult to estimate accurately and may not contribute to understanding the work to be done. Work items that are too small waste planning time and effort.
Example
For our example, let’s plan Iteration 4.
Review/update the iteration mission
The mission for a hypothetical iteration is shown in Table 1.6:
|
Release plan |
Iteration use cases |
Iteration user stories |
Effort (hours) |
|
Functionality |
Predict the Bike Fit with a Camera |
||
|
Estimate the Bike Fit from External Parameters |
|||
|
Monitor the Distance |
|||
|
Calibrate the Power Output |
|||
|
Provide Basic Resistance |
|||
|
Set resistance under user control |
|||
|
Target Platforms |
First-run factory electronics Hand-built mechanical frame |
||
|
Technical Work Items |
Finalize the flywheel mass |
||
|
Spikes |
|
Table 1.6: Iteration mission
Select work items from the backlog
These work items are selected from the product backlog and placed in the iteration backlog.
Break use cases into scenarios or user stories
Figure 1.24 shows the planned functionality for our hypothetical iteration of the Pegasus bike trainer. The ovals without stereotypes are use cases that are decomposed with the «include» relation into user stories.
Each of these is then estimated to get an idea of the scope of the work for the iteration:
Figure 1.24: Iteration planning example
Break user stories into tasks
These user stories are all pretty small, so this optional step is skipped.
Estimate effort for work tasks
We then estimate the hours required to complete these small work items for the task. This results in the updated table in Table 1.7:
|
Release plan |
Iteration use cases |
Iteration user stories/work items |
Effort (hours) |
|
Functionality |
Predict the bike fit with a Camera |
Access the camera image |
2 |
|
Retrieve the road bike dimensions from the camera image |
16 |
||
|
Compute the fit parameters from the road bike dimensions |
4 |
||
|
Estimate the bike fit from the external parameters |
Load GURU bike fit data |
4 |
|
|
Load trek bike fit data |
4 |
||
|
Compute fit from professional fit data |
2 |
||
|
Monitor distance |
6 |
||
|
Calibrate power output |
12 |
||
|
Provide basic resistance |
20 |
||
|
Set resistance under user control |
4 |
||
|
Target platforms |
First-run factory electronics Hand-built mechanical frame |
||
|
Technical work items |
Finalize flywheel mass |
4 |
|
|
Spikes |
|
||
|
Totals |
78 |
Table 1.7: Iteration 4 mission with estimates
Put tasks into the iteration backlog
Work items from the Iteration User Stories/Work Items column are added to the backlog for the iteration.
Evaluate team loading
The six-person team executing the iteration should be able to complete the estimated 78 hours of work in the 2-week iteration timeframe.
Adjust the team
No adjustment to the team is necessary.
Adjust the backlog
No adjustment to the backlog is necessary.
