So obviously, I haven’t posted anything on here for months, for a variety of reasons. But recently, I discovered 750words.com, which is quite awesome at forcing you to express your thoughts, even if you don’t think you’ve got any particularly worth expressing. The idea is, you sign up, and write 750 or so words, every day. They’re not published, it’s not a blog, so stream-of-consciousness is the order of the day. And guess what? Today, without even setting out to, despite having no idea what I’d be writing about when I sat down, I wrote what will form the bulk of this post. I wrote about the practice of estimating, as carried out in planning games, planning poker et al.
First off, a quick outline of how my current team runs a planning game. There’s no real need to read this properly, just skim it, or don’t even bother reading it. It doesn’t matter, really. Ours is a relatively typical planning game, probably erring on the side of slightly better than average. It goes like this: The team sits around a table, and our product owner has a bunch of cards he wishes to present to us, each card being a typical user story. “As a user I want to put pictures of lolcats on my website”, that sort of thing. The product owner presents a card, which basically means he reads out the description, and then the QA engineer goes through what acceptance criteria have to be satisfied for the card to be considered ‘done’. Once this is done, the devs have an opportunity to ask questions about the card and the acceptance criteria. We might ask one another how this work should be done, we might question whether it should be done at all, we might adjust, add to or remove acceptance criteria, or decide that the card should be broken down into smaller cards. Often, the card is self-explanatory and clear enough that we don’t bother with this at all, and just move straight to estimating. The underlying question is always “Do we have enough information to estimate this card?” Once we do, we estimate, which involves us simultaneously expressing how long we think the card will take, by holding up cards with some numbers on, or fingers, or smartphones with numbers drawn on the screen in some way. We then decide, based on this, what we as a team are estimating. This might be as simple as taking the majority vote, but if there’s a large discrepancy, such as a really low estimate and a really high estimate, further discussion ensues. When we finally reach a decision, the estimate is written on the card, and we repeat the exercise with the next card. Estimates are made in ideal pair-days, which is a day of typical effort from a pair of developers working on the card, and we can estimate anything from 0, up to 3 pair days, in increments of half-days. Anything above that, and we have to break the card down. This exercise is repeated for each card. It can take hours.
If some of the above sounds a bit tedious, you’re not far wrong. Planning games are tedious, and for me, the entire approach is riddled with assumptions which are just accepted as being right, where they really ought to be challenged. Not least of which is that there’s a need to do them at all. If you skimmed over the description above, good for you, you’re probably already agreeing with me. Estimating how long our work will take, like having a hierarchical management structure, is one of those things we just accept as a fact of life, when of course there’s no real reason for it to exist, unless there is an actual reason, of course. An expressable reason, mind you, not simply a variation on “because that’s how it works.” Sometimes, there can be a good reason for an estimate. It’s not entirely unreasonable for someone to want to know when they’ll get the thing they asked for. But here’s the thing: in our planning games, if estimating a particular card takes a long time, or we seem to be struggling to reach a decision, someone – usually the scrum master – reminds us that it is only an estimate, and we’re not obliged to be exact about it. So what’s the point then? We’re not drawing up any charts of how long things take compared to how long we said they would – we don’t have that sort of information factory running – and nobody gets overly concerned if a card goes over or under its estimate. There isn’t anybody watching us saying “You’ve got half a day left to get that card done.” A feature takes as long as it takes to implement, and that’s that.
Not to mention that we, as a species, are pretty rubbish at estimating anyway.
I’ve worked in places where estimating is abused. Typically, if an organisation starts holding you to your estimates, you start holding them to your estimates too. Say I estimated something at 3 days, and got harrassed when I was still at it 4 days later; I’m not going to get my work done any quicker, I’m just going to over-estimate the next one to give me some leeway. In some circumstances, people will grossly overestimate work, so they can get it done in a fraction of the estimated time, and use the extra time to dawdle, and piss about. I’ve seen it done, I’ve probably even done it. Luckily, where I work now, we don’t foster that. Nobody holds anybody to an estimate, we just do the work, and when it’s done, pick up the next card.
Which makes me wonder yet again, why we bother with the estimates in the first place (are you getting the idea yet?)
Another flawed assumption is that a pair-day is a consistent measure of effort. Sure, we call it an “ideal pair-day” but the underlying assumption is that a task will take any combination of any of our devs the same amount of time to complete. Nonsense. We all have different skillsets, strengths and weaknesses. Of course, the mantra “it’s only an estimate” is repeated again in mitigation of this flaw, where really it should be an alarm bell, a smell, something telling us we’re doing the wrong thing.
As for the limit of 3 days for a card, that is simply bizarre. To pretend that we know, in advance, the maximum amount of time any feature will take to implement, whilst simultaneously claiming to have adopted a working practice that explicitly exists because such things cannot possibly be known in advance, is frankly bizarre. Of course, the counter-argument to this is that anything longer than 3 days should be broken down into shorter cards. Well, maybe. Sometimes, that might make sense, and I’m all in favour of fine-grained stories, but quite often you’ll find that we’ve broken the card down simply because we’re not allowed to estimate it at 7 days, but actually talk about the feature as a whole, and don’t consider it complete until both cards are done. So right there, we’ve put our process before our customers and ourselves. So much for “individuals and interactions over processes and tools”, eh.
As an experiment, in our next planning game, I’m going to suggest that we estimate every card the same, regardless of what we think of it. Say, 1 pair-day per card. Then see if anything’s different at the end of the iteration. My bet is, it won’t be. This gives much more leverage to the argument against estimating. Conversely, if something is different, that gives us something to focus on, a part of our process that is perhaps working better than we thought, and that’s equally a good thing. I’m not married to the “drop estimating” idea, which is exactly how it should be. I’ll post the results, if any, when I get them.
One final thing: if you’re reading this and thinking “But we need to estimate to make sure our devs are actually doing some work!” then I think you’ve got bigger problems to worry about. Trust is a big deal to a dev team – if you trust us to get on and deliver what you’ve asked for, there’s a good chance we’re going to exceed your expectations. Act like we’re a bunch of shirkers, looking for an opportunity to skive, and you’ll see productivity drop through the floor. I’m yet to see an exception to this rule. Srsly.