Three Ways to Manage “Extra” Work in an Iteration

Many of my clients use an iteration-based agile approach. And, they have these problems:

• They “push” too much into an iteration. They use velocity, not cycle time to estimate.  They rarely finish everything before the iteration ends.
• They have to manage extra work—work they had not estimated—in the form of an emergency or production support.
• The business people (I'll use the PO as the representative) want to take advantage of some change in the market. The PO wants to change what's in the iteration.

One of the managers I coached asked this question, “Is there any way to estimate ‘right' for two weeks at a time?”

It depends on the kinds of problems you need to solve.

Why are you using an agile approach? If you have deterministic problems, you might be able to estimate for more than two weeks at a time. If you have problems in the middle of this image, two weeks might be the maximum you can estimate for, and then, only if you have one-day stories.

If you're using an agile approach because you want to embrace change, then no, there might not be an answer to the “estimating for two weeks at a time.”

However, you don't have to do without estimates altogether. You have other options.

Understand Why You Have Extra Work

Before you decide how to proceed, take a few of the emergencies and retrospect or do some form of a root cause analysis. Why did these emergencies occur?

• Did the team not quite finish the work and not meet the acceptance criteria?
• Did the team meet the acceptance criteria but no one realized how the users would use the feature?
• Is the team working around technical deficits that have come home to roost?

I see these problems a lot when the product owner has feature-itis. Or, when a team doesn't have the conversation to confirm what they have in a given feature. Or, when the team(s) works across the architecture, not through it.

If your team isn't finishing features for any number of reasons, do consider the first possibility of shortening the iteration.

Possibility 1: Shorten the Iteration

If you can't fit “everything” into a 2-week iteration, move to a 1-week iteration. If you still overestimate/push too much work into a 1-week iteration, move to a 3-day iteration. Still too much? Move to a 1-day iteration.

Why? Because you will have to clarify the stories and make them smaller. (See Consider Product Options with Minimum Outcomes.)

And, a shorter timebox limits the team's WIP (Work in Progress). And, often, the team has to collaborate to move the work to done. Those actions reduce the cycle time, so the team can see what it does take to finish work. (See Measure Cycle Time, Not Velocity.)

Now, you have data about how the team can work in either a 2-week or shorter timebox. You can decide how much room to leave in an iteration for unplanned work.

Well, unless all you do is unplanned work. Then, it's time to change your approach.

Possibility 2: Use a Flow-Based Agile Approach

There is not One Right Way to use an agile approach. I happen to use flow in my business with a cadence of planning and retrospectives. (See
Thinking About Cadence vs. Iterations for the difference between a cadence and a timebox.) (I wrote about this topic in detail in Create Your Successful Agile Project.)

I like a cadence of planning, demos, and retrospectives. The big difference is the team doesn't try to commit to finish a certain amount of work by a particular deadline.  And, a flow-based approach limits the team's WIP and each column's WIP.

A flow-based approach can also help a team see if they have all emergency work. One team thought they had “too much” production support. They were correct. One very sharp PO decided that since the team always completed production support work, he would put all his requests in as production support.

Once the team changed their board to seeing all the emergencies and they calculated their cycle time, they confronted the PO. And, the PO's manager.

Possibility 3: Learn to Say No

The “too much” work problem is not a function of the agile approach. Instead, it's about someone's inability to say No to more work.

I wrote a series about that problem. See the series that starts with Visualize Your Work So You Can Say No. I also recommend you create as many columns as you need in your board so you can see if you have any bottlenecks or wait states.

Saying No is an art. Here is some reading and a video:

• Do You Have Too Much to Do?
• Learn to Say “No” and End Your Multitasking! (a video of my talk at Agile Prague.)

What Can You Do to Manage Your Iteration's Worth of Work?

Of these options, what can you do? Start with a retrospective or root cause analysis about why the team has so much “extra” or interrupting work.

Then, ask the product owner and the team to discuss the product determinism. How much discovery do you need right now? If much more discovery than delivery, manage your WIP and use small stories. I would not bother working in iterations if you might need to change what you do several times a week.

If you have more delivery than discovery, make the stories smaller. Use minimums and calculate your cycle time. Those approaches will help you reasonably estimate what you can do in an iteration.

The keys to all approaches:

• Smaller stories.
• Use cycle time to estimate.
• Manage the team's WIP.

Good luck, and let me know if you see or use other possibilities.