Milestones are like a progress bar indicators for internal stakeholders, they give everyone involved feedback on the progress. In different software I have come across at least three different progress bars, the first quite easily reach 90% then stalling and you’re wondering if stopped. The second one just shows that it’s working and never stall but you don’t know how much work that’s left. The third one gives you the feeling that it’s accurate and that it’s adopt in order to give you a realistic estimate. Even if the progress bar says it’s a long time left you prefer that because then you can do something else. Sincere (Swedish: uppriktigt) estimation is more valuable than working in the dark and hoping that the first 50% of the work will be evidence that the 50% of the remaining work. But this is not so easy as it sounds. Let’s look on some aspects of tracing progress.
Your project is getting closer to a release deadline and you ask the lead developer, “How’s is it going? Are we going to ship in time?”
“Hmm, something have come up!”, she tells you, “I have done really great for the last 4 weeks, but today I found something no one have thought of and the timetable slipped 3 month.” How big chance is that? Quite small I will say. Because timetable slips don’t happen at the end of the milestone or project. Slips just show up at the end. But they happen every day and every hour. As soon someone answers an unexpected e-mail, have to be home with sick kids or tracking down an intermittent but catastrophic bug, slips happens. These things are also important and needs to be done but the sooner you can identify how much that’s left and if there is a timetable slipping risks the better time estimation it will result in. Team members and stakeholders will be more able to trust the timetable.