Milestone: Lessons learned

or: Why milestones are good for you

I find making project schedules and estimates an absolute pain. Neither painless schedules a la Joel, our internal “process” nor any tools I found so far, make this easier. Why? I am not sure, but I think one thing I am missing is some basic theory how to make a good schedule. The problem if you have a bad schedule is that you are not keeping it up to date because it was inaccurate when created.

So what now? My latest experience taught me something that I want to share and would like some feedback on, of course.

One thing that many projects seem to be using are so-called “milestones”. I remember them being mentionned in the software engineering classes at university. But I cannot remember what was being said. Now here I present my theory why “milestones” are good for you. It’s going to be short, so you can go back to scheduling your project 😉

Defining milestones is not so hard, once you think about it. They can be big blurbs like “I want to be able to store something in the database and retrieve it again” or “I want to execute that task” or “I want to execute several tasks parallel”. They gave me a rough roadmap of what kind of “tests” I wanted to be able to execute at what point in the project. I just completed: “I want to see all the components of the Foo-package work together minus Feature A,B and C”. For me milestones are tests. They define in very broad terms something I want to complete. It’s top-down design and actually I am using that approach for a bunch of things, it just wasn’t clear to me. Milestones aren’t code or anywhere close to it, thinking about it when talking to project/product managers I usually try to describe them the next step they are going to actually “see” the project take. Those are milestones, even tough I never realized it.