Striking a different bargain with the business

Comments (3)

Print This Post Print This Post

Email This Post Email This Post


Iteration planning is another core element of Scrum. Scrum divides the calendar up into fixed-duration time boxes. Traditionally, this is 4 weeks, though some teams make it shorter. Scrum aims to limit disruption of work-in-process by the business, so the 4 week iteration cycle includes a planning window where the business is allowed (expected, even) to adjust the content of a backlog of pending work requests. Of the prioritized backlog, the team estimates the scope of work they believe they can deliver in the iteration and sets a goal to do that.

The bargain with the business is that the stakeholders have a time to have their say, but otherwise are expected to leave the team alone to complete their goal. In a nutshell, Scrum’s expectation of the business is:

You may not interrupt work in process, and you may not adjust the work plan more frequently than once every n days.

Our teams strike a different bargain with the business:

You may not interrupt work in process, and you may not adjust the work plan less frequently than once every n days.

But…if the business can come in and change priorities any time they like, how can you commit to a goal?

A scope-driven goal is only one kind of goal. We don’t make that kind of goal. Another kind of goal is quality of service, and that is what we do. The team commits to deliver working features, on average, within a time limit that we consider a Service Level Agreement, or SLA. A typical SLA for us would be something on the order of 30 days. The engineering team’s promise is:

When we agree to take on a work request, we intend to deliver it within n days.

According to this criterion, it doesn’t really matter what the work is in the backlog. It only matters that the work has been appropriately sized and has been specified with a reasonable amount of clarity. This also greatly simplifies estimation by setting a single sizing criterion: not too big to meet the SLA. And if you don’t make a scope-driven goal, then there’s no such goal to meet and no need to package any such group of features together for delivery.

So we don’t do that either.

What we do instead is agree to release all of the features that have been completed since the prior release on a periodic interval. Because the amount of work that is in process is limited, that means that the rate of features exiting the process has to be the same as the rate of features entering the process. Some features are bigger, and some features are smaller, but on average, most releases will be of a similar size.

This kind of arrangement means that the planning interval and the release interval don’t have to be the same. Which means that there are no time boxes and no iterations. The planning interval should be often enough to keep the input queue from starving. The release interval should be set to the optimum point between the cost of deploying a new release vs the opportunity cost of carrying finished inventory. If the cost to release is high, you’ll want to release less often. If the cost to release is low, you’ll want to release more often. Cost of release is a worthy target to optimize and the ideal result is deployment on demand.