Alex Ponomarev

Javascript web development notes and experiments

Notes On Estimating and Planning software projects

Destructive pattern of not meeting deadlines you set for yourself

During the last few years I've been working mostly with small startups building MVP's of all sorts. Typical project involves me as a developer, designer and architect of an app and a client who acts as a project manager and tester. There is usually a feature outline in a one-page Google document and I, as a developer with vast experiance must estimate and plan the project.

Until some time ago we had the same destructive pattern repeating: I calculate estimates for several phases of the project and then systematically fail to meet the deadlines I set for myself. Given that my clients or me don't have experience in software project management you can imagine to what kind of frustration this leads. So I decided to learn how to manage projects and teach my clients how to do that. Turned out it's quite easy if you're disciplined enough.

Estimating time in the beginning of the project is always a guess

You just have to admit it — during software project development you have to deal with a lot of uncertainty, especially at the earlier stages, which makes estimation in the very beginning very hard. Another pitfall is that we, developers, are always optimistic when thinking about how much time something will take. And finally, it's a known thing that first 20% of the project takes 80% of time since that's usually a phase when you set things up —this is what I personally forget all the time. All these obstacles makes estimations and planning nothing more than a guessing.

But every client wants an estimation before you start, right? This is understandable because there are business goals and metrics, budgets and deadlines for a project, but we already know that our deadline will be a guess, or should I call it a lie? What should we do?

First option is to spend fair amount of paid client time on writing down all requirements and throughly researching everything. But you know that it would still be a guess because it's just an estimation, project requirements usually change over time, users and clients change their mind and a lot of things happen. Another option is to admit that estimation is always a guess, not a commitment. This way you can spend less time examining the requirements and make estimation and planning an ongoing process during the project. The more knowledge you will gain during development the better your estimations will be, plus you will have data on your performance, which gives you a good base to make educated decisions about the project. That's what agile project management aims for and that's what I'm going to tell you about.

You must have detailed user stories before starting of the project.

Remember that one-page Google document I was talking about about? This is not enough to start a project, because usually what client means when saying 'user management' and what developer will image will be two different things. That will lead to wrong estimation, poor planning and in the end will stress out both parties. Common thing here is to think that we'll just start working and get into details during the project. Both clients and developers tend to think so and this is so terribly wrong. Without knowing what exactly you are doing and where you are going it's very hard to make decisions. What database structure should we user? Which feature should we develop first? Which feature has more value and which will take more time?

To answer all these questions we must write down user stories. A user story is just what its name says — a description of what user should be able to do with the app. For example user should be able to click an item, edit its name, and name should be validated. Oh, so we have validations for names, right? Who knew. Believe me, if you are building something decent these small things quickly become very important. If you have a huge project it's nearly impossible to write down stories for all of the features, but you will split project into phases (or releases) anyway, so make sure you have stories for at least couple of first releases. Note that it will be impossible to estimate project at least approximately without stories, so if you'll have them for couple releases that's all you'll be able to estimate (and that would be still an educated guess, remember?)

I must note here that it's really important for a client to write down stories. Yes, it takes time, but it also makes you think about the project and how things work together. Having detailed stories will save you from finding yourself near the deadline still 'refining' second line from that 'outline' google doc — I've been there and that's quite painful. Note that it's important is to focus on user actions and not on technology like what animations to use or what database entities should be created, but of course this depends on the project.

Estimate your stories and get back to them on a timely manner

So you have successfully avoided commitment to an unrealistic deadline and managed to describe your goals in the form of stories. Now you have to estimate them, but how to do that if we know that estimations are just a guess? Again, we must admit that we are guessing and estimate stories using relative values or points using your experience and gut feeling. Of course, when working in a team it's good to have all team members involved to tell their estimates. There's even things for that like Planning Poker, there's plenty of info about it online so and in every book on agile project management so I'll just skip that part.

Crucial moments here are:

  • estimate stories by effort required to implement them rather then hours or other time frames
  • estimate all stories using the same scale
  • estimate stories relative to each other
  • be consistent with your estimations throughout the project

Let's say you have a scale of 1-8 points and you estimated first story 'User must be able to sign up with email and password'