What is the underlying science behind iteration size selection?
For some background reading I refer readers to Donald Reinertsen’s book: The Principles of Product Development Flow. One of the book’s chapters is about batch size, and sets out a dozen ‘principles’ that promote the merits of smaller batch sizes. In the context of software development, Waterfall executes a software release in a single batch, whereas scrum breaks up the requirements for the release (the Release Backlog) into a set of smaller batches, and implements these in a sequence of Sprints. The question we have is: what is the optimum size for a sprint?
Much research has been done on determining the optimum batch size in the context of manufacturing logistics. The calculation of ‘optimum’ batch size – usually called Economic Batch Quantity (EBQ) – is based on the relationship with annual demand, machine set-up cost, and inventory carrying cost per item. Specifically:
|EBQ = sqrt(2*Annual Demand*Setup Cost/Inventory Holding Cost per Unit)|
where the inventory holding cost is the overhead cost associated with each item, and generally increases with the size of the batch, and the setup cost per item generally decreases as a function of batch size. This can be illustrated in the following chart:
Fig. 1: Optimum Batch Size
For manufacturing operations the impact of large batch sizes on cost and throughput may be fairly obvious: large batches increase work-in-process inventory levels, materials lead-times, and finished good stock levels. But more importantly, large batches drive more variability, and more variability means more re-work, more cost and delays.
We will look at exactly what this means for software, but before that, what we really care about is maximizing throughput, i.e. how do the maximize the number of User Stories (or Story-Points) delivered per sprint? The throughput chart is simply the inverse of the cost chart above, and will be an inverted U-Curve.
Let’s separate the production costs of User Stories into direct costs – those that contribute directly to the definition, design, coding and testing of each story, and indirect costs – those that represent overhead.
The fixed costs are associated with the fundamental development tasks that must be carried out to deliver the set of User Stories in the iteration: design, coding and testing. Building 100 user stories in a batch as opposed to building 1 at a time yields obvious economies of scale. (Think of test automation as an example). However, as the size of an iteration goes up, so too does the amount of indirect cost, examples of which include dealing with more complex branch merges, fixing broken builds, scrubbing long lists of bugs, plus all of the data collection and status reporting that goes with this. The simple fact of having to deal with an iteration of larger scope and complexity drives up the amount of overhead one encounters in a project. Thus the overall cost/story vs. iteration size graph will be quite similar to that in Figure 1.
The larger the batch, the fewer opportunities there are to inspect and adapt, and the more we are exposed to WIP and re-work. It is up to each team to find their own sweet spot for the size of an iteration. In scrum, we talk about getting to an ideal ‘velocity’, or the optimum number of Story Points per Sprint. Teams should pursue this objective by searching for and eliminating all sources of delay in their development process.