Batch Cycle Planning and Tracking Guide

Compendium / Development Process / Batch

Overview

This guide covers my preferred approach for planning an iterative cycle in Batch processes like Scrum’s Sprint Planning or XP’s planning. The biggest influence to my cycle planning approach outside of my own experience has been Mike Cohn‘s Agile Estimating and Planning (Cohn, Mike (2004) Iteration Planning. In Agile Estimating and Planning. Boston, MA: Pearson Education.).

Outcomes of Effective Cycle Planning

When cycle planning is used as intended, the team should experience the following outcomes:

• Confidence throughout the team in the commitment made for the cycle
• Shared understanding and agreement upon the implementation approach being taken for each outcome in the planned cycle
• Increased understanding of what it takes to complete work as a team, and respect across team members for the roles played by their partner disciplines

Assumptions

This guide assumes the following things:

• You have a cross-functional team where there are multiple skillsets whose schedulable hours need to be considered.
• The team has a queue/backlog of work expressed as outcomes, and those have been created, discussed, and estimated by the team.
• The team is entrusted to take requested outcomes and determine the implementation approach through a combination of their expertise and clarifying dialog with necessary parties.

Aliases

Other names for Cycle Planning in Batch processes include:

• Sprint Planning
• Iteration Planning

Before Cycle Planning

Ahead of the planning event, take the following steps to prepare:

1. Ensure you have your current throughput or velocity as a directional guide of capacity for the cycle. However, assess your actual capacity in schedulable hours before planning a cycle. The available taskable hours per discipline is a far more accurate indicator of the team’s capacity for the upcoming cycle than relying solely upon a rolling average of how the last N cycles played out. I still use a rolling average of six cycles to calculate throughput, which I first learned from Mike Cohn in 2004.
2. Check with team members to see who may be unavailable for part of the cycle so that their taskable hours can be reduced accordingly.
3. Check the company calendar to see if any department or company holiday, meeting, or event is happening in the cycle so that team-wide schedulable hours can be reduced accordingly.
4. Prepare a Cycle Planning and Tracking spreadsheet to have a lightweight means of knowing how many taskable hours remain throughout the Cycle Planning event. An example of the spreadsheet I have used for many years is available as a Google Sheet named Batch Cycle Planning and Tracking Worksheet – Simple, which you are welcome to copy. The Cycle Planning tab looks like this:

Determining Taskable Hours

For teams just starting out with planning against pools of taskable hours per discipline, I recommend starting with 4 taskable hours per day for all but the first and last day of the cycle.

I occasionally encounter managers who are quite rattled by the above guidance, and insist that their team members have 7 or 8 taskable hours per day. This usually reflects a naive understanding of how work happens and just how much of a given day is spent in meetings and other types of administrative overhead.

Some teams find that they need to drop down to 3 taskable hours per day, while others are able to go up to 5 taskable hours per day. I rarely see teams go to 6 taskable hours per day in a sustainable fashion.

The nature of a team’s work will determine how much of their capacity in a cycle is available for schedulable work. Teams with a service aspect to their work or who spend some portion of their time supporting those who use their software will have less capacity for schedulable work than teams without those responsibilities.

Taskable Hours Example

The following example assumes a Scrum team with a 2-week sprint, with 4 taskable hours per day:

Here’s how the team arrived at those amounts of taskable hours:

• Front-End: Both team members are available for the full cycle, so 4 taskable hours X 8 middle days of the cycle = 32 hours for each of them, for a total of 64 Front-End hours.
• Back-End: The single Back-End team member is available for the full cycle, so 4 taskable hours X 8 middle days of the cycle = 32 hours, which is the total number of Back-End hours available this cycle.
• QA: The single QA team member is available for the first 7 days of the cycle, but will not be with the team for the last 3 days of the cycle. Only 2 of those are middle days of the cycle, so 4 taskable hours X 6 middle days of the cycle = 24 taskable hours, which is the total number of QA hours available this cycle. (The QA team member said something about needing stay in Crickhollow for some mock object experimentation, and the team all agreed the benefit was worth the reduction in taskable QA hours.)
• UX: The single UX team member is also allocated to another larger endeavor that takes up most of his time and energy, so he is partially allocated to this team for 2 taskable hours per day. He is available for the full cycle, so 2 taskable hours per day X 8 middle days of the cycle = 16 hours, which is the total number of UX hours available this cycle. Allocating team members across more than one team is a separate topic. For the time being, see Ask an Agile Coach: What Team Members can be shared across multiple Scrum teams? if you seek guidance.

During Cycle Planning

I recommend holding Cycle Planning in the morning of the first day of the cycle, not too long before lunch if possible. During the meeting for planning the cycle, facilitate the following steps for the team:

1. Concisely recap key themes for the cycle, the current state of the team’s metrics, and the available capacity for the cycle based upon team availability.
2. Place a card for the first backlog item on the board, briefly stating what it is (read the User Story; if it’s not a story, summarize whatever the outcome is), and state how much effort (usually in Story Points) the team has assigned to it. If the item is stored in an application where acceptance criteria and clarifications have been captured, sharing that on a large screen in big enough text for the whole room to see can be helpful.
3. Have the team begin writing tasks that it will take to deliver the outcome. Watch the team to see if good discussion about implementation approach is happening, particularly across disciplines. For example, if your back-end engineers are generating lots of tasks with no discussion with front-end engineers or QA, ask open-ended questions of either group to prompt interaction.
4. As team members place tasks on the planning board, enter the number of hours under the appropriate discipline column for each task. A typical Cycle Planning tab in progress looks something like this:

5. When it seems like the team has created all the tasks needed for the backlog item being planned, ask it the team feels if everything has been captured. If needed, briefly walk through the tasks that have been captured, asking open-ended questions to clarify any vague areas, particularly where different disciplines need to collaborate or accomplish an effective handoff.
6. Before pulling another backlog item, assess the remaining schedulable hours for each discipline. If sufficient capacity remains, pull the next item from the queue/backlog, and repeat steps 2 through 4 until the schedulable hours for one or more of the disciplines has been exhausted.
7. When any of the necessary taskable hours are exhausted or almost gone, inform the team of the remaining hours for the cycle, and that that the team does not have capacity to deliver any additional outcomes. The most typical case is that the disciplines that are under-represented on the team have no more hours, as seen in the progress of our example team:

8. It is possible to ask the team if there are ways to make use of the excess capacity in the disciplines with significant amounts of capacity left, but avoid having them start work whose completion relies upon the disciplines that are already out of capacity. Failing to heed this warning creates a rolling deficit of unfinished work whose cost of effort is amplified because the work being done is based on many assumptions that have not been vetted with the unavailable team members.
9. Keep an eye on which disciplines are consistently under capacity. Keeping track of this can be a great way to make a strong case for more headcount in that discipline for the team.

After Cycle Planning

Do not book other meetings follwing Cycle Planning; allow space for the team to spin up the cycle. There are often infrastructure tasks and discussions that need to take place as the team begins this next batch of work.

1. Transfer the physical board items used in Cycle Planning to the team area, and create the Development Log for this cycle.
2. Notify dependent teams and stakeholders of the outcome of Cycle Planning. Preface any detailed list with a concise, readable summary of what the team has projected to complete in this cycle.
3. Populate the Cycle Tracking tab of the planning and tracking spreadsheet with the roster of schedulable work the team has planned, filling in the story points and total tasked hours as of Day 1 in the appropriate columns as shown here:

Middle Days of Cycle

For the days of the cycle between the first and last day, stay alert and keep an eye on how the cycle is progressing for the team. Pay attention to what team members are saying in their daily updates. Read their non-verbal cues as well as what they are saying. A common failure I see in Team Stewards is to treat the execution of a cycle as mere mechanical tracking of tasks.

1. Each day at the same time, update the hours remaining on all the tasked work in the cycle and record that in your cycle tracking. I recommend updating the tracking right after the Daily Standup, as it is a natural point of synchronization for the team.
2. Watch for outcomes whose hours remaining are either staying the same or increasing. This can be an early indicator that an outcome is either larger or more problematic than the team had imagined during Cycle Planning. Ask the team for context around why those items do not seem to be progressing.
3. Evaluate whether variation in progress on some outcomes may mean that the team might not complete everything planned for the cycle.
4. If changes to the cycle plan need to happen, confirm changes with the team, and communicate to dependent teams and stakeholders. This creates the opportunity to make informed changes to the cycle, removing or reprioritizing items based on the input of those who are expecting the work to be delivered. As one client of mine used to tell his teams, “I’ll take bad news over surprises any day.”

Additionally, ensure that Backlog Grooming and Backlog Maintenance are happening and that the sessions are effective for the team. These events ensure that the team is maintaining a healthy-well structured queue of work that can flow smoothly through execution and provide the opportunity to look ahead at big items coming up to see if design spikes or architectural discussions are warranted.

Cycle Tracking Example

To illustrate how the Cycle Tracking tab can provide insights into how a cycle is progressing and when the plan should be adapted, let’s review the final outcome of the example team’s cycle tracking:

Here are a few key insights from tracking this cycle:

• Day 5: Halfway through the cycle, the plan seemed to be intact, even if the team was not as far down the board as they had expected. The waggon packing’s tasks seem to have been over-estimated, and the Crickhollow-themed work seemed to drag on, but overall, things seemed acceptable. One notable change was that the level of effort for crossing the Brandywine seemed to have been sharply reduced as the team found a more expedient if not harrowing alternative to their original plan.
• Day 7: Following the apparently fruitful discussion of team charter, the team decided to scrap taking the road to Bree in favor of using the Old Forest. While the level of effort was considerably higher, the team cited other concerns in the acceptance criteria that made this more costly outcome desirable.
• Day 10: While the team ended up with some amount of carryover at the end of the cycle, in context the tradeoffs chosen did seem to be the right direction. There’s also plenty of opportunity for discussion around why some outcomes ended up being more or less effort that they thought, and why some outcomes of an average size seemed to drag on for days.

Last Day of Cycle

The final day of a cycle should be focused on landing the delivery of the items that could be completed in the cycle and reflection within the team upon how this cycle went.

1. Ensure that the Cycle Review is focused on the outcome of the cycle and not simply demos of work. A common failure is to allow a dysfunctional focus on demos to creep into a team. When demos figure too prominently in Cycle Reviews, the well-intended, enthusiastic response from stakeholders and dependent teams can cause teams to care more about impressive demos than solid delivery of outcomes.
2. Update your cycle tracking with the likely outcome of the cycle. Resist the urge to make a cycle look more perfect than it is. You will be able to update it with the actual outcome at the end of the day.
3. Facilitate the Cycle Retrospective as a discussion among the team, not merely a narrative by the Team Steward. Where applicable, use your cycle tracking and Development Log to give the team a picture of how the cycle played out, so that more meaningful discussion can take place.
4. Based on the state of work by end-of-day, finalize the outcome of the cycle. Communicate the outcome of the cycle to dependent teams and stakeholders, using artifacts like the Development Log to illustrate the value the team has delivered.
5. Add the outcome of your cycle to your ongoing tracking of throughput and committed-to-completed ratio. Use the latest values of those metrics as you prepare for the next cycle.

Further Exploration

• Four Outcomes of Effective Development Process
• The Iterative Cycle: Commit, Execute, Evaluate