Customer Facing Information
What Is it?
Any system where management writes a schedule and hands it off to programmers is doomed to fail. Only the programmer who is going to do the work can figure out what steps they will need to take to implement that feature. And only the programmer can estimate how long each one will take. In this document, we are trying to follow simple guidelines.
Who will use it?
Programmers, Managers, and dev teams, in general, need this guide in order to plan proper scheduling.
How is it used?
Attempting to estimate a feature before you’ve figured out how the feature is going to work, in detail, can’t possibly work, even if you “multiply your best guess by three,” because your “best guess” is based on very little in the way of facts. The nature of software development is that things which seem simple are often surprisingly complicated when you think about all the details. For example, when you think about creating a registration and login system, you might forget that you’re going to need a way to prevent passwords that are the same as the username, and a way to deal with forgotten passwords, and a way for people to unregister, and so on. Until you try to figure out the design of all these things, you have no basis for an estimate at all.
Break things down to very small tasks
This is the most important part of making your schedule work. Your tasks should be measured in hours, not days. (When you see a schedule measured in days or even weeks, it’s probably not real). You might think that a schedule with fine-grained tasks is merely more precise. Wrong! Very wrong! When you start with a schedule with rough tasks and then break it down into smaller tasks, you will find that you get a different result, not just a more precise one. It is a completely different number. Why does this happen?
When you have to pick fine-grained tasks, you are forcing yourself to actually figure out what steps you are going to have to take. Write subroutine foo. Create dialog such and such. Read the wawa file. These steps are easy to estimate, because you’ve written subroutines, created dialogs, and read wawa files before.
If you are sloppy and pick big “chunky” tasks (“implement grammar correction”), then you haven’t really thought about what you are going to do. And when you haven’t thought about what you’re going to do, you just can’t know how long it will take.
As a rule of thumb, each task should be from 1 to 16 hours. If you have a 40 hour (one week) task on your schedule, you’re not breaking it down enough.
Here’s another reason to pick fine-grained tasks: it forces you to design the feature. If you have a hand-wavy feature called Internet Integration and you schedule three weeks for it, you are doomed, buddy. If you have to figure out what subroutines you’re going to write, you are forced to pin down the feature. By being forced to plan ahead at this level, you eliminate a lot of the instability in a software project.
Track actual times and learn from your mistakes
Most programmers have no idea how to guess how long things will take. That’s okay. As long as they are continuously learning and continuously updating their estimates as they learn, the schedule will work. (You may have to cut features or slip, but the schedule will still be working correctly, in the sense that it will constantly be telling you when you have to cut features or slip). Most programmers become very good estimators with about one year of experience.
Account for vacations, holidays, meetings, etc.
If your schedule is going to take about a year, each programmer will probably take quite a few days of vacation. In FogBugz, you can set up company-wide holidays, and each developer can enter their own planned vacations as well.
Add schedule items
You need to enter schedule items for:
- Integration time, that is time spent getting code written by different developers to work together.
- Buffer time: extra time in each developers’ schedule to account for unplanned features and tasks. This may need to be as much as 50% to 100% of the planned time, depending on how much confidence you have in the accuracy of your design.
- Competitive buffer time: time to allow for new features added at the last moment to match a competitor’s features.
- Debugging time: time spent fixing bugs discovered during testing.
- Alpha and beta tests: time spent distributing test versions of the software, gathering and responding to feedback and bug reports, incorporating feedback into the product, and fixing bugs discovered by beta testers.
In FogBugz, a schedule item is a special kind of case. You should enter schedule items for each developer. If you have five developers on your team, you should have five “debugging” schedule items, one assigned to each developer, so that the calculated dates produced by EBS are correct.
Note, Schedule Items still take into account a developer’s velocity when calculating dates are produced by EBS.
Ignore business needs (and your manager)
Many rookie software managers think that they can “motivate” their programmers to work faster by giving them nice, “tight” (unrealistically short) schedules. This kind of motivation is brain-dead. Most developers, when behind schedule, will feel doomed and depressed and unmotivated. When they’re working ahead of schedule, they’re cheerful and productive.
The business is best served if estimates are as realistic as possible. While estimating, you must completely ignore the wishful thinking of the client and focus on what is really going to happen.