Iteration Planning & Review

You now have all the tools you need to begin your iteration planning. As a reminder:

At the start of every iteration, your team will need to meet around your task board to review the work done in the last iteration and the planned work for this upcoming iteration. Generally, the meeting should be about 10 minutes per team member (e.g. a 5 member team would have a 50-minute meeting), but you should also provide some buffer time in case greater discussion is needed on specific tasks.

The meeting should be very hands-on. Go through the task board, update and move tasks, and assign out to individuals. For meaty discussions that you know will take time, schedule them to be discussed in another meeting and only invite the members that are impacted. Me. A few pages back.

Meeting agenda

For your iteration planning & review meeting, you'll want a single person to drive. It doesn't matter who the driver is. You could have a designated driver, you could rotate it. Keep it simple. All that matters is one person is going to need to share their screen of the task board and do all the clicking. The driver doesn't necessarily lead the meeting, but it's easiest if they do as everyone knows what happens when you have a back-seat driver.

Each meeting should follow a very deliberate routine. The more your team practices the routine, the faster and simpler the meeting will be. You can set your own routine, but we use the one below for our planning and it works great.

Update tasks' completion history and status

For each task that was worked on, update its completion history by asking the owner of the task how much progress was made on the task. As a refresher on the completion history:

[The completion history is] a log of the owner's best guesses on how far along the task is going from "In Progress" to "In Verify" stages as a percentage.

Generally, a task shouldn't be >50% complete if it is still untested and shouldn't be >90% if it isn't merged/pulled into the main branch.

I highly recommend keeping a completion history in a format like so: 40->90->100. Where the latest number is the completion percentage at the end of the current iteration. Any previous number is the previous iteration's historical completion percentage. Me. A few pages back.

As an example: if Bob had a task that right now is 80% completed and the task already had the completion history of 30, the task's completion history should be updated to 30->80.

Update velocity tracking

For each task that had its completion history updated, you'll want to update your velocity sheet with these updates. Velocity tracking is a topic on its own. We'll get to it later. For now, just keep reading blissfully ignorant of this step.

You may want to have someone else in the meeting (other than the driver) update the velocity sheet as the driver is filling in the completion history. Since this is simply a busy work step to update the sheet, you can speed up the meeting by working on it in parallel.

Review velocity trends and noteworthy tasks

Now that you have a good sense of how the last iteration went, you should take some time to review the finer details that were unexpected. Did a task take twice as long to complete as expected? Did someone have to shift focus on items not accounted for in the iteration? Was there a subtlety or issue caught that everyone should be aware of?

This is not a blame game. Iterations do not go as planned. Engineers don't always get it–whatever "it" is–right. Dig into the deeper reasons. Use the 5-whys or other tactics to distance people from the problem so proper critical analysis can take place. If you can help your team feel comfortable sharing why the iteration went as it did, you'll discover insightful ways to improve as a team and develop a culture of growth and learning.

Troubling tasks

Sometimes a task itself is significantly more complex than it appeared when first estimated. This is quite common. Depending on the code and architecture, seemingly challenging tasks can be quite trivial, and seemingly trivial tasks can be quite challenging. Don't be afraid to either split up a task into multiple parts or update its story point estimate (even retroactively, after they've been completed).

Surfaced bugs

Sometimes a task uncovers a bug that is either too important to ignore or that blocks the task's completion. Make sure to create a ticket for the bug (with the "bug" label) and talk with your team about whether or not it should be introduced into the iteration. Generally, once you start your iteration, the goal is to not introduce new tasks, even bugs. If the bug can wait, put it on the next iteration to address it.

Move unfinished tasks to the next iteration

Whatever tasks weren't completed during the iteration should be moved to the upcoming iteration. If the task is completed but not fully reviewed or released (such as a coding task in a pull/merge request or waiting for release), you may leave the task in its previous iteration as a way to keep things organized.

Customer Issues

Review any outstanding customer issues or bugs. Typically, these tasks take the highest priority for the upcoming iteration, bumping other tasks off of the iteration if there is no room.

"There are too many of them!"

If you find the number of bugs overwhelming, you'll want to hone in on this before it gets out of hand. There are a lot of great resources on this topic. I'd recommend starting with investigating SRE best practices. The problems, however, are likely very specific to your company and you should take the time to understand and resolve them.

Fill the next iteration with the highest priority tasks

Consider what other high-priority tasks you, as a team, would like to accomplish for the upcoming iteration. When you have what you believe to be a full iteration of tasks, you should get them organized in priority rank-order.

There are many strategies for prioritizing tasks. I personally like the concept of the Eisenhower matrix (another great article on it) while also considering urgency trapping; however, I use these techniques often as a back-of-the-mind reminder more than a tool. If you have timelines or deadlines, make sure to stay far ahead of them. If you have an upcoming release, consider what should be on that release. Common sense is typically all that is needed to help prioritize.

Assign tasks using predicted velocity

Once prioritized, start at the top and assign tasks to different owners. Usually, it's best to let each team member pick their tasks. I also like one or two engineers focused on a user story rather than having the whole team invested in it (see Shallow Silos). How many tasks should you assign to a member? Easy peasy. Take the number of story points that the person completed last iteration (calculated as part of the velocity) and assign them tasks that equal that in their estimated story points. If they have a remainder of story points, give them one more task assuming that –if everything was estimated accurately– they would only partially complete that task by the end of the iteration.

For example, Bob's completed 4.2 story points worth of tasks last iteration. So he is forecasted to complete 4.2 story points this iteration. He takes a task worth 1 story point and another worth 3 story points. He still has 0.2 story points remainder, so he takes a 2 story point task, with the assumption he will only partially complete it by the next iteration.

Bump unassigned tasks to the backlog or the next iteration

For all tasks that you don't have the velocity to complete, either bump them to the next iteration (to be reviewed during the next iteration planning meeting) or put them on the backlog.

Congrats! You have now completed your iteration review and planning meeting! Well... except for that velocity tracking stuff. We'll tackle that next!