Realistic schedule is one of the most important criteria to deliver quality software on time. One must schedule to succeed and not to fail. People don’t plan to fail but they fail to plan. This article discusses some best practices prevalent in the industry today. 

Schedule to Succeed: Most projects start without much realization into the capacity and capability of the software development teams. Though, it is hard to measure, it is always good to review the past performances of the project team with respect to total number of lines added/changed/modified, time taken to complete N number of features along with total number of defects produced. Such information should help one to schedule a project more realistically.

Stepping Stones: Another important thing to consider in scheduling a project is that one should have small and meaningful milestones as opposed to overwhelming one. This will help the team to set clear and concise short term goals and be more focused to achieve them. Accomplishing such small milestones will motivate the project teams in moving forward towards completion of the project. Teams should celebrate such small milestones together to build strong cohesiveness among their team members which will lead to increased productivity through intense collaboration and cooperation. Presence of such small milestones will also help the software manager to track the progress without micromanaging the team.

Identify Deliverables: Everyone in the team from QA, to development to documentation team should have frequent deliverables. This builds interdependency in the team. Often time the estimation for completion of the task is done by the project manager or the team lead which is not at all realistic. The schedule for completion of task should come from the owner of the task. Everyone in the project team should be consulted while making a schedule otherwise the schedule is a bunch of arbitrary numbers that does not reflect the reality. Team members are more likely to buy into a schedule if they participate during its creation rather than having it come down from above.
Software schedules should consist of a large number of fine-grained tasks, not just a few monolithic milestones. Break tasks down into smaller tasks until they cannot be broken down any further—the unit of measurement should be hours or days, not weeks or months. Small tasks provide small successes, which motivate people and make them more aware of their contribution to the whole.

Track Progress: Once the original time estimate is established, track the team’s progress. Updating the schedule takes only a few minutes a day, and doing so allows the team to compare the original estimate to its current progress. The schedule is an active document that must be revised constantly throughout the project. Part of the purpose of scheduling is to help identify when it is time to change the schedule. If the current estimate is wildly different from the original estimate, it is time to re-evaluate your feature list.

Estimate Debugging Time: If you don’t plan for debugging time, your original estimate and your current estimate will be very close through 75 percent of your project. However, in the last 25 percent of your project, everything will go wrong. Unfortunately, debugging is the most difficult task to provide an estimate for. Essentially, you are trying to guess when you will come up with a creative solution for a problem. There is no true way of knowing. As a general rule, allow as much time for debugging a feature as you allowed for developing it. One way to minimize debugging time is to have developers debug code as they write it. No untested code should ever be permitted in the build (more on that later). However, this process will never totally eliminate debugging time. Inevitably, near the release, beta testers and QA will find more bugs. There must be time built into the schedule to fix these bugs.