Right-Sizing Iterations
How many Use Cases can be put in an iteration? Can everything be “priority 1”? How long should an iteration be? We will address each of these questions.
Iteration Length
Scrum literature typically assumes a 4-week iteration. The PAT recommends smaller iterations to hedge against volatility inherent in the WITS environment. The PAT recommends that WITS employ 3-week iterations. The start and end of any iteration comes with the overhead of iteration planning and reflection. This makes smaller iterations have more overhead as a proportion of overall iteration work time. In that respect, smaller iterations are less efficient. Often there is a strong temptation to lengthen iteration. However, longer iterations provide less control and greater impact resulting from a troubled iteration. In general, longer iterations should be reserves for teams experienced in agile methodologies working in a stable environment. The PAT believes that 3-week iterations are the appropriate balance of these concerns for WITS.
Iteration Size
The amount of LOE (as defined but estimates) that an iteration can hold is computed based on several factors.
- How many working days are in the iteration (not counting time for iteration planning and reflect)?
- How many people are working on development?
- In the WITS environment, what amount of LOE is likely to be drawn away from the iteration from priority O&M task?
The following shows an iteration capacity calculation.
The Max Iteration Capacity here is 31.2. That means that the sum of all priority 1, 2 & 3 elements in the iteration should not sum to more than this amount. Elements at lower priority can be added to the iteration for the team to do if they are ahead of schedule and are looking for other work to do. However such elements are an “unofficial” part of the iteration. They will not be counted in the burn-down chart discussed below.
In the above table, it computes a “Generally, no task should be more than” value. In this case, that value is 40% of the Max Iteration Capacity. The point of this is to avoid having elements in the iteration that are so large as to be in any jeopardy of not being finished by the end of an iteration if they are started in the first half of it. If the team estimates an element at more than this value, then the Requirements Lead and team need to break it up into meaningful pieces that can be delivered separately. These pieces mush have a business functional value, and not be technical horizontal pieces such as “database queries”, “web page HTML,” etc.
Iteration Prioritization
We cannot have everything in an iteration be priority-1. But how much is reasonable? The PAT is recommending rule-of-thumb thresholds for the LOE associated with each priority. The following table shows the details, with the cumulative thresholds in blue.
For priority-1, 45% is set as the threshold. This means: for the 31.2 LOE capacity iteration, no more than about 13 staff days of LOE can be assigned as priority-1. The thresholds are cumulative; at the priority-2 level, the sum of the LOE estimates for priorities-1 and 2 can be no more than 80% of the total iteration capacity. At the priority-3 level, which account for all LOE officially in the iteration, all of the priorities-1, 2 and 3 LOE must sum to no more than 85%.
Essentially, the team is aspiring to complete priorities-1, 2 & 3 during the iteration. But if it gets behind, it will definitely get all of the priority-1’s done (barring exceptional circumstances) and will almost certainly get all of the priority-1 and 2’s done. All things going normally, the team should be able to complete all work at priorities-1 through 3 because it has a 15% buffer.
Should the team proceed at a faster pace and complete all priorities-1 through 3 work prior to the end of the iteration, it will then pick up additional work that is at a lower priority. Also, toward the end of the iteration, all of the priorities-1 through 3 elements may already be completed or are currently being worked on. A staff member may complete his work and not be in a realistic position to help with the rest of the work. And so he may pick up a low priority task to do.
The team should avoid starting new tasks, even low priority ones, if they would be a risk of not completing them by the end of the iteration. This applies to low priority tasks that team members may want to pick up at the end of an iteration. Therefore, such low priority tasks should be very small. The team may also wish to not start low priority tasks at all. It is at the team’s discretion to assign free resources to work on such things as testing and code refactoring so long as it meets the expectation that it completes all priority -1, 2 & 3 work.
Scrum Iteration Burn-down Charts
The Scrum process tracks iteration process via a "burn-down chart". Essentially, we sum up all of the LOE estimates for each thing we have in the iteration and make a graph of how much is left to do after each day. And here is the catch: we don't get credit for the "burned LOE" associated with some iteration task until it is entirely complete (there is no such thing as 80% complete. It is either 0% or 100% for purposes of this chart).
Consider the following Chart:
The dashed reference line represents an ideal burn-down trend, where each day we make (and are given credit for) an equal advance toward zero work left at the end of the iteration (weekend days have zero burn-down, making the line a little wavy). This linear burn-down never happens in real life; it is the statistically expected value, like when you roll one 6-sided die, the expected value 3.5 (=average of 1,2,3,4,5,6) yet there is no "3.5" side.
The blue line is our actual burn-down. In the above chart, it is the beginning of the iteration. No items are yet reported as complete, and the blue line it is at the top. The following chart shows the end of the iteration wherein the blue burn-down line shows the actual data during the iteration.
Example Scrum Burn-down Chart
In this example, the blue "actual" line crosses the reference line indicating at that point the team is burning-down more quickly than expected. This means that the team is ahead of schedule. In this case the team finishes by May 23. At that point, low priority items that are not "officially" part of the iteration, can be undertaken.
Initially, the blue "actual" line is staying above the Reference line. A quick, and incorrect, interpretation is that the burn rate is too slow. But remember: since we don't get credit for burned-LOE until its feature is finished, the blue actual tends to lag due to "latent" burned LOE.
Another example: look at the line between 16-May and 19-May. The line stays flat as nothing is completed during this period. Then suddenly there is a sharp fall in the following few days. That pattern is typical. It means that work was being done on some features during that period and the work was completed on the 20th whereupon the team finally got credit for it. Typically, the blue "actual" line tends to look more like a step function rather than a sloping line.
Aside: this step-like effect gets more pronounced with smaller team sizes and/or larger-LOE features and it and becomes less so as team sizes and number of scope items in the iteration grow or feature LOEs get smaller. Think of it as the "chunkiness" of the iteration. Ideally, we want to minimize chunkiness by having small LOE items.
If the blue line is well above the reference line, then the team may be in jeopardy of not completing everything that it initially set out to do. However, at the beginning of the iteration, the Requirements Lead prioritizes the features. Toward the end of the iteration the team must make a conscience choice of what low-priority items not to start. The team should never start anything that it cannot finish by the end of the iteration. At the end of the iteration, all bets are off. The Requirements Lead may choose to completely change the priority and direction of the development. Since prioritization may shift for the next iteration, we don't want to leave partially-developed/untested code that we may not get back to. Think of this philosophically as ensuring that the codebase is in a well organized or "low entropy" state at the end of each iteration.
The yellow line on the burn-down chart tracks items that have been started but are not yet completed. Whereas the blue line gives credit only when a task finishes, the yellow lines gives credit as soon as a task starts. The thing to look out for is that the blue and yellow lines do not diverge too much. Divergence means that many things were started but are not getting finished. It is better to get only a few things done inside of an iteration than to end and iteration with many things started but not completed.
The difference between these two lines is the “In-Play” profile. The graph of it (derived from the graph above) is shown below. An ideal profile would stay at a constant level until the end of the iteration when it would diminish then go to zero. Look out for variations, especially increases, and investigate if the team is stuck on a technical issue or is otherwise being delayed by external forces.
This metric can serve as an early warning indicator that an iteration is in jeopardy.
