The First Law of Development

In my post, What’s so Wrong with Pushing, I showed by analogy how Time Blocked Iterations, Story Points and Burn Down Rate enabled a superior pull mechanism over traditional management for development teams.  In this post, I’ll develop how to maximize results from that pull system.

There are three, sometimes opposing objectives in maximizing the effectiveness of development teams.  We want to maximize the throughput or story points delivered from a team.  This gives us more features – an obvious benefit.  We also want to minimize the cycle time to create those features so that we build them quickly – another obvious benefit.  But, we also want to minimize the work in process or features being developed at any given time.  This is a less obvious, but equally important objective.  Benefits of minimizing the work in process are that it:

·         Ensures the team is fully focused on the most valuable features
·         Clarifies requirements and acceptance criteria
·         Allows more flexibility by delaying decisions until facts are most clear
·         Simplifies communication
·         Minimizes the impact of defects
·         Minimizes impact of changes or new understanding

This applies to all activities of an iteration for each feature: requirements, design, build, test, deploy. 

Let’s use desks to represent those activities and imagine a development process where features go sequentially through the five activities.  The desks don’t represent number of people on the team, just iteration activities. Each feature has some value of effort assigned to it or number of story points.  We’ll use pennies to represent the number of story points being worked.  If our objective is to maximize burn down rate and minimize the iteration time, what number of story points should the team have in process at once?  

In manufacturing workshops, I’ve run this setup as a simulation with three scenarios, where the number of pennies is 2, 5, and 8.  For simplicity, we assume each activity takes the same amount of time, say half an hour (simulated in minutes) per story point, and only one story point can be processed in each activity at a time.  New story points can only enter after another one has finished all activities. After running this for 8 simulated hours, which scenario delivers the most story points fastest?  Actual results closely follow the graph below:  

From this graph, it should be obvious that at some critical number of story points being worked (5 for the simulation,) the team’s productivity (burn down rate) is no better, but they will work longer to complete each story point (Iteration time grows longer.)  In fact, there is a physical relationship between these elements which creates my First Law of Development Physics:

            Iteration Time = Story Points in Progress / Burn Down Rate

This relationship will be obvious to agile managers and teams. It is fundamental to the process of pulling work into agile teams. Perhaps not as obvious, is the important inflection point in this relationship which defines a needed optimization:

            Burn Down Rate_best = Iteration Time / Story Points in Progress_critical 

  and     Iteration Time_optimal =  Burn Down Rate / Story Points in Progress_critical 

In practice, there are no story points sitting in developer’s inboxes, so the components of this equation are measured empirically in the first few iterations of development.  Philosophically, it is important that the concept is kept at top of mind so that the three components are always being balanced for maximum overall benefit by releasing as close as possible to the crucial number of story points into each iteration and monitoring burn down rates closely.