Continuing on the theme of company principles (see one), a second decision we made early on was that we would always break work down into very granular chunks. Initially this meant less than 4 hours, and more recently has come to mean below 2 hours.
At the outset this was from a sense of fear that the numbers I was estimating for clients needed to be as accurate as possible because I would be held to them, even if not contractually. And the only way I felt I could be close to 100% sure that an estimate is correct was to have identified every single aspect of the work to be done.
This mean enumerating every button on a website, every api call on a server, and generally every task that I could see in the brief.
This turned out to be a good call, largely because almost always it showed up work that no-one had thought of at the time. And sometimes things I thought were complex turned out to be simpler.
It also had the secondary benefit that estimating these issues became much easier. It is far far easier to estimate 1 hour on a button than it is to estimate 1 week on a login page.
It’s a slight break with the pure agile development model, because our issues are more like a mix of issues, stories and tasks, but overall our issues make sense to both a developer and a human so it works for us.
I also believe these small issues helped helped us to avoid one of the big pitfalls of a software development, which is under-estimating how large a project is and so having difficult deadline and budget decisions during a project. And it gave us an easy conversation with clients about project scope, because instead of discarding whole features, we could fine-tune any feature at the granular issue level.
It’s not perfect, since it does require a new type of grouping at the reporting level or the proliferation of issues quickly becomes unmanageable.
But I’ve never regretted the work that comes from speccing even a 6 month project at this sub-4 hour granularity, because overall our estimates, and therefore our proposals, are the better for it, even when the project inevitably changes after the first sprint.
(continue to avoidable admin)