To keep in mind for your next project
Article from Martin Fowler: FivePoundBag. Martin Fowler is the author of some excellent books about Agile development, namely Refactoring and Planning Extreme Programming (with Kent Beck).
The tendency is to say “hmm, let’s see, we have this big features over there, we have this much time, yeah, I think I can make it fit, we should be fine”. I know that if I hear this one more time my head won’t explode, because I’ve been hearing this all my (professional) life, so I suppose I’m used to it by now :) We just take it as inevitable, as cost of doing business. We can do better.
Here’s what I try to do so I can sleep well at night:
1. Write stories or use cases or scenarios: These are things that a user would say “Today I need to
For example “display the list of emails sent to me” is a story (if I am writing an email client). But “IMAP” is not a story for that same project because no user would say “Today I need to…IMAP”. IMAP is “just” a component.
In a previous life I worked for a startup here in the Silicon Valley where we would implement component after component, not really understanding what the value was for the users. It was some really cool technology, lots of novel ideas. We did really cool stuff but ultimately users didn’t care, we were just a box of cool features, nothing more. The company doesn’t exist anymore. I’m not shocked.
2. Now that I have these user stories, or at least a good chunk of them, I work with the user or an expert or whatever to prioritize the stories. I avoid doing it alone, because I know I’ll put the cool stuff on top and I might wind up implementing the really cool LDAP/BER address book for my email client, before the budget runs out, and then I have something really cool from a technical point of view, but totally useless to the user.
3. Break the first stories into 1-2 day tasks. Anything that I would guess “a couple of weeks” really means “at least a couple of weeks” so I stay away from it, because it means I really don’t know. Breaking features down to tasks that can be done in days is hard. But that’s why we’re professionals. Having these one-day tasks is a huge step, it’s design!
4. Now that I have some rough design (or not so rough, but I definitely don’t have big architectural diagrams at this point), I can start implementing things. Ideally “Test first”, so my code is always fully unit tested.
5. Keep track of how long these tasks really take. If a 1-day task ends up taking two days, that means my next tasks are likely to take twice as long (this is called “Yesterday’s Weather”). I then adjust my schedule accordingly. If I thought I could implement 30 stories in 30 days and the first story, and the second, and the third, take 2 days each, then I can really do 15 stories in 30 days or 30 stories in 60 days. No ifs, no buts. The list is prioritized though, so the important stuff gets done first.
6. I keep adjusting it. At first I have no choice but to say “it’s going to take 30 days give or take 15 days”. The more I do the better I know how accurate that is. Soon enough the margin will be measured in days, not weeks (for a 30-day project). But just saying, before I even write a single line of code “it’s going to take 28.52 days” is very precise but not accurate at all. I *hope* it’s true, but I *know* it’s not.
7. Repeat