For any closed loop control system ‒ let’s assume we want to manage our project with such a system ‒ has a signal representing the current state of the system. For software, this can be value produced (assuming we have a unit of measure for that value in the for of effectiveness, performance, key performance parameters, or technical performance measures). https://goo.gl/DP6Jw is an overview of this process.
To control this process using feedback and corrective actions ‒ in the same way, your closed loop controller for your air conditioner or heater does - a sampling rate is determined based on the rate of change of the underlying processes.
For a software project, let’s start by answering a critical question – how long are you willing to wait before you find out you’re late? For your Honeywell or Nest controller on the wall, that sample rate is measured in seconds. So the answer to the software question needs to be determined by two things for a closed loop control system:
- The pace of software deliverables – if your sampling the state of the software outcomes longer than you are producing those outcomes, errors unfavorable outcomes are accumulating faster than you are measuring them.
- The response to change rate ‒ how fast can you make corrective actions to the system to keep it on plan. The plan can be the temperature of the room. It can be the speed of your car. It can be the cost, schedule, and technical performance measures of the software project.
These measures, corrective actions, and resulting outcomes operate in the presence of statistical and probabilistic processes. Stochastic process control is the field of study. I cut my teeth writing FORTRAN 77 code for the control system for flying, driving, and swimming machines and then for stationary machines, like a power plant, refinery and paper mills.
For the software machines the principles of closed loop control in the presence of noise and changing conditions are the same ‒ https://goo.gl/cUcXNj
The sample rate is also applied to the target to steer toward – the set point in the case of the temperature or cruise control. The estimate of Desired (or even contractual) schedule, cost, or technical performance of the software project.
The granularity of these estimates determining the dynamic behavior of the system ‒ the software project. Too large and accumulation of errors occur. Too small and wasted information is produced and possibly even over controlling the system.
When we hear the question at what level of an agile project do we estimate – Vision, Theme, Release, Feature, Story, or even Task ‒ the first question is again
How long are you willing to wait before you are late, or the room is too hot, or you've driven into the ditch, or the radar station steering control has lost track with the incoming target, or your exothermic reactor has gone over-temperature and blown up?
This answer tells you the granularity of the control systems sampling and corrective actions as well as telling you the granularity of the steering target needed to maintain control of the underlying process.
So don't let anyone suggest estimating at any level - Feature, Stroy, or Task is right or wrong until they can answer...
- How long are you willing to wait before you find out you are late?
- What is the dynamic behaviour of the underlying process?
- How much error debt are we willing to build up before taking corrective actions?
- What are the consequences losing lock on the corretive actions (the project is out of control)?
- What is the value at risk you are willing to right off if you lose control?
Managing software development projects is a Closed Loop control system. Subject to all the principles and practices of Closed Loop control. Any suggestion of another method of managing must be tested against these principles first before continuing the conversation.
