Our interest in applying Agile practices to embedded software began in earnest about a year and a half ago. (You can read about our continuing adventures on our Embedded Software page and at this blog’s Embedded Corner.) After several projects under our collective belt, we’re now at the point of working on a very large and complex embedded project with X-Rite, one of our longtime clients. So far things are going quite well. For this project we’ve been using good Agile-style planning and tools like burndown charts. And, we’ve been learning some important things about successfully using Agile planning in embedded projects.
For more on the Planning Game see the links in the “planning” section of this page. Also, planning poker and burndown charts provide good background as well (note: the example burndown chart doesn’t illustrate the normal fluctuations in a project’s feature set over time).
In the Planning Game developers estimate the complexity of stories (features) in points. From this, the team can then measure the velocity of accomplishing complexity points over time. In general, humans seem better suited to estimating the relative complexity of tasks rather than the actual time necessary to complete them. The techniques of the Planning Game give quite accurate metrics towards predicting future completion dates and understanding the rate of progress towards that goal (successful estimation should, of course, deliver these very things).
When we started the X-Rite project we decided among different point scale schemes for representing the relative complexity of individual user stories. Since our entire approach to embedded development was new to all of our X-Rite colleagues we settled on a very simple 1-10 scale (10 representing the greatest complexity) to make it easier to explain and involve everyone. This scale has worked just fine for most of our stories. But, if we had to do it all over again, we would perform our estimation differently.
We’ve learned by experience an important lesson. Anytime one of our user stories has involved writing driver code for hardware features it invariably has been estimated on the high end of the complexity scale. What reality has revealed as we’ve implemented hardware features, however, is that hardware-centric programming is deceptively far more complex than “straight code” (straight code being logic only with no explicit setting of registers and the like). Nobody on our team has been at all surprised by the complexity involved in writing hardware-centric code. We all know how it goes. What has been surprising is how inadequate our upper-end-of-the-scale complexity estimates have been. It’s as though hardware code exists in another complexity dimension apart from pure algorithms or other “software only” programming.
Our team has done some reflection on better ways to handle embedded software project estimation. Some of the ideas discussed to date include using a multiple-of-two scale (1, 2, 4, 8, 16, …) or a Fibonacci-inspired scale (1, 2, 3, 5, 8, 13, 21, …); these are fairly common in Agile estimating. We also talked about complementing such a scheme with the practice of automatically bumping up our first team estimate on any hardware-related code to the next position on the scale; for example, if estimate poker produced an 8 for a given hardware-related story we would record a 13 instead. Perhaps another approach is sticking with the 1-10 scale but using an empirically derived multiplication factor for hardware-centric user stories.
In the end, our experience with estimating hardware-centric user stories has revealed that there are really two distinct buckets of complexity in embedded project estimation. Hardware-related code lives in a different dimension. It is probably at minimum twice as complex as that which on first blush might be considered an equivalent software-only feature. After a bit more progress on this project, I think we might be able to arrive at some sort of empirically derived scheme/multiplication factor to relate hardware and software-only programming.
