As developers, we are very good at breaking up components into sub-components - sometimes exceedingly so. When confronted with a larger than average chunk of work, we make a choice: either consider the work as indivisible to be delivered in its entirety, or break it up smaller pieces. Most of us already experience a sense of foreboding when confronted with a piece of work that is too large. Whether you are estimating in hours or in story points the question is: when breaking up work items into smaller pieces - how small is small enough?
Delivering software, one piece at a time
By now, we know that the best way to write software is to evolve it bit by bit. Doing work in small chunks allows us to
- free our minds of details that are not relevant to the here and now
- make small, certain steps towards a goal
- measure progress as soon as it happens
- get feedback as soon as possible
Too much of a good thing can also be bad for you - too many small tasks could cause the overhead of managing these tasks to become significant in itself, and measuring progress could become a nightmare. Also, when estimating on very fine-grained (low-level) tasks, local safety typically becomes a problem.
How small is small enough?
One way of determining the appropriate size for a piece of work could be to link it to the notion of testability - the smallest piece of functionality that could be finished and pushed through the delivery pipeline. Unfortunately, this approach produces way too many small, very fine-grained work items, tightly linked to their technical implementation.
Rather, a story should represent a single piece of deliverable business value:
The rule here is to make the story as small as possible, yet that it retains some measurable amount of intrinsic value - something that, when demonstrated to the end users, they’ll agree is an improvement to the system.
We can test work item size by looking at the value delivered:
Conversely, if you break a story into two pieces, but there is no value to be had until both pieces are completed, then that is too small. The stories should be recombined - or split another way.
Optimizing the flow
It is also very important to consider the idea of single piece flow. In manufacturing terms :
Single piece flow is the ideal state where parts are manufactured one at a time, and flow throughout the manufacturing and supply chain as a single unit, transferred as customers order.
Manufacturing large batches of parts simultaneously, or accumulating parts in a bin for shipping or transferring 2 or more parts at the same time is opposite or contrasted to the definition of Single Piece Flow.
The idea is that large batches of work (the waterfall way) equate to rework (waste), inventory (also considered waste), and delayed delivery time (loss of profit). There are, however, times when work items should not be split up into smaller pieces. Since the existence of software is solely linked to profit (businesses do want to make money, don’t they?), it makes sense to optimize for flow and profitability by
- sharing setup costs, that is, group items where setup cost can be shared, and
- maximizing flow by minimizing batch size.
When breaking work into chunks, a careful balance needs to be struck between the two.
Photo by Céline Haeberly on Unsplash