Project planning requires and understanding of both product features and schedule

Project planning requires and understanding of both product features and schedule

When creating a new project plan, should it be driven by product features or by schedule?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Both the features and the schedule will need to be taken into account when creating a project plan. The project manager needs to understand both the product and schedule requirements. Sometimes, the schedule is the primary driver. For example, perhaps the project team may be committed to putting out releases at regular intervals and they do not have flexibility with schedule. In this case, it must be determined what features can be delivered in the given timeframe. Many agile teams are strict about their iteration timeframes and their delivery schedules, but are more flexible with the features, pulling from a backlog of features, determining at the start of each iteration which features will be included in that iteration.

The traditional approach in software development is to determine all the features for the release up front and estimate how long it will take to complete the design, development, and test of those features. The tasks required to complete these efforts are mapped out and an end-date is estimated. Once again, both features and schedule are taken into account, but this approach focuses more on the features, and often the initial end-date is a target and the schedule is adjusted if requirements change or there are delays in finishing the development efforts of all the features.

As Robin Goldsmith explains in Reliably estimating the requirements effort, part 1, there are different ways in which we estimate. "Top-down estimates make a single estimate for the whole thing and allocate that estimate among the major work pieces." In this case, a final date might be estimated and then the project manager would work backwards to determine what tasks need to be completed to accommodate that schedule.

In the second part of this series, How to complete requirements assessments from the bottom-up, Goldsmith defines bottom-up estimates as an approach that "breaks down the expected work into task and sub-task pieces, estimates each piece, and rolls up the estimates into the estimate for the total." This approach is more feature-driven.

Both of these approaches need to take into account both the product features and schedules when building a plan. Each plan you make will include tasks that must be completed and an estimated release date. Both of these are important for a successful release. The flexibility you have with each will depend on your project. The stakeholders should weigh-in with their thoughts on the importance of features vs. schedule, and the priority of each.

This was first published in June 2010

Back to top