Scheduling and Release Planning

Introduction

Software projects rarely fail because a team cannot write code. They often fail because work is sequenced poorly, dependencies are misunderstood, scope is released without adequate validation, or stakeholders hold different expectations about dates and outcomes. Scheduling and release planning convert a product vision into a time-oriented plan for delivering usable software.

A schedule describes when activities are expected to occur and how they depend on one another. Release planning determines which capabilities will be delivered to users, in which release, and under what quality and readiness conditions. These activities are related but not identical: a schedule focuses primarily on work and timing, whereas a release roadmap focuses on product value and delivery increments.

A professional plan is not a promise that every date is certain. It is a transparent model of assumptions, constraints, dependencies, capacity, risk and decision points. It should be sufficiently detailed to coordinate work, yet flexible enough to accommodate learning and change.

Learning Objectives

By the end of this chapter, a student should be able to:

• decompose software scope into schedulable activities;
• identify dependencies and represent them in network diagrams;
• create and interpret Gantt charts and milestones;
• calculate early and late activity times and identify a critical path;
• distinguish schedules, baselines, iteration plans and release roadmaps;
• plan releases using capacity, priorities, quality criteria and risk;
• use project tools responsibly to monitor and revise plans; and
• explain limitations, governance concerns and ethical issues in scheduling.

1. Foundations of Software Scheduling

1.1 From product vision to activities

Scheduling begins with scope. A product vision such as “provide secure online assessment” is too broad to schedule directly. The team decomposes it into deliverables, features, user stories, technical activities, testing activities and management tasks. A work breakdown structure (WBS) organizes this decomposition hierarchically.

A useful activity is sufficiently clear that its completion can be verified, assigned to an owner, estimated and related to other work. Activities should not be so small that administration dominates delivery, nor so large that progress cannot be assessed reliably.

For example, “implement assessment submission” may be decomposed into interface design, API implementation, database changes, automated tests, security review and user acceptance testing. The decomposition should include non-coding work. Requirements clarification, environment configuration, documentation, accessibility testing, deployment and training can all affect the release date.

1.2 Important terminology

• Activity or task: A unit of work with an identifiable start and finish.
• Duration: The amount of working time required by an activity under stated assumptions.
• Dependency: A logical relationship that constrains the order or timing of activities.
• Milestone: A zero-duration event used to mark an important decision, completion or approval.
• Deliverable: A verifiable product, document, service or result.
• Constraint: A restriction such as a fixed deadline, limited staff or required technology.
• Assumption: A condition treated as true for planning purposes.
• Baseline: An approved version of scope, schedule or cost used for comparison.
• Iteration: A time-bounded cycle that produces an integrated increment.
• Release: A version made available to users or another operational environment.

1.3 Estimating duration

Duration is not the same as effort. Effort is the quantity of labour, often measured in person-hours; duration is elapsed calendar or working time. Two people may complete 16 person-hours of work in more than one calendar day because of coordination, interruptions or sequential constraints. Adding people does not always shorten a task and may increase communication overhead.

Estimates should state assumptions: team availability, working calendar, technical familiarity, environment readiness and definition of done. A range is generally more honest than a falsely precise number. In an agile setting, historical throughput or velocity can support planning, but it should be treated as evidence rather than a guaranteed production rate.

1.4 Types of dependencies

The most common dependency is finish-to-start (FS): activity B cannot start until activity A finishes. Other relationships include:

• Start-to-start (SS): B may start after A starts.
• Finish-to-finish (FF): B cannot finish until A finishes.
• Start-to-finish (SF): B cannot finish until A starts; this is uncommon.

Dependencies may be technological, logical, resource-based or external. A database migration may be technologically dependent on a schema design. A review may be logically dependent on a completed draft. A task may be resource-dependent because only one specialist is available. An external dependency may involve a vendor, regulator or customer.

A lag adds waiting time between related activities; a lead permits controlled overlap. Both should be documented because they affect interpretation of the plan.

2. Network Diagrams and Critical-Path Analysis

A network diagram represents activities and logical relationships. In the activity-on-node convention, each activity is shown as a node and arrows show dependencies. The diagram is not a calendar: it shows sequence and constraints, while dates are calculated or assigned separately.

2.1 Forward pass

For a simple finish-to-start network with no calendars, the forward pass calculates the earliest start (ES) and earliest finish (EF). If activity duration is measured in working days:

where d is duration. If an activity has predecessors, its earliest start is the greatest predecessor earliest finish:

The maximum is required because activity j must wait for every predecessor. The project earliest completion is the largest EF among terminal activities.

2.2 Backward pass and float

The backward pass calculates latest finish (LF) and latest start (LS) without delaying the project completion date:

For an activity with successors, its latest finish is the smallest successor latest start:

Total float, also called total slack, is the amount an activity can be delayed without delaying the planned project completion:

The critical path is the continuous path through the network whose activities have zero total float under the stated model. It determines the shortest possible project duration for that network. A project can have more than one critical path, and the critical path can change as estimates, progress and dependencies change.

These calculations assume fixed activity durations, known dependencies, a consistent time unit and unlimited availability of required resources. Real projects also require resource levelling, calendars, uncertainty analysis and judgment.

2.3 Worked example

Consider the following activities, measured in working days:

Using a time origin of day 0:

• A: ES 0, EF 3.
• B: ES 3, EF 7.
• C: ES 3, EF 5.
• D: ES 7, EF 12.
• E: ES max(5, 12) = 12, EF 15.
• F: ES 15, EF 17.

The earliest completion is 17 working days. The controlling path is A–B–D–E–F, whose durations sum to 3 + 4 + 5 + 3 + 2 = 17 days. Activity C has one day of apparent float because it finishes at day 5 while E cannot start before day 12; however, its actual allowable delay should be confirmed through the backward pass and resource analysis. A visual network would make these relationships easier to inspect, but the calculation demonstrates why a task that is short may still be important if it feeds a critical successor.

2.4 Limitations of critical-path analysis

Critical-path analysis can create false confidence when durations are uncertain. It also assumes that resources are available when needed. If two activities require the same specialist, the resource constraint may create a new critical sequence. A schedule should therefore show risks, assumptions and resource conflicts rather than presenting calculated dates as facts.

3. Gantt Charts, Milestones and Baselines

A Gantt chart displays activities against a time scale. Bars represent planned durations, links represent dependencies, and milestones identify significant events. A useful Gantt chart can show planned and actual dates, percentage complete, owners, dependencies, baseline variance and status.

Gantt charts are valuable for communication because managers and stakeholders can quickly see overlap, sequencing and approaching decision points. They become ineffective when they contain hundreds of low-level tasks, when progress percentages are subjective, or when bars are moved without recording why.

Milestones should represent outcomes or decisions rather than arbitrary dates. Examples include “architecture approved,” “first integrated increment accepted,” “security assessment completed,” “release candidate built” and “production release approved.” A milestone should have an owner and acceptance evidence.

A baseline is an approved reference plan. Schedule variance can be described as the difference between an actual or forecast date and its baseline date. A simple date variance is:

The unit is normally calendar days or working days, and the sign convention must be stated. A positive value may mean lateness if later dates are positive. Baselines should be changed only through an agreed change-control process. Otherwise, repeated re-planning can conceal poor performance and destroy historical learning.

A baseline is not a commitment to ignore change. When approved scope or assumptions materially change, a revised baseline may be appropriate, provided the old baseline is retained for traceability.

4. Iteration Planning and Agile Scheduling

An iteration plan is a short-horizon commitment for a development cycle. It normally contains a selected set of stories or tasks, acceptance criteria, technical work, test activities, owners and a definition of done. Iteration planning should begin with a clear objective, not merely a list of convenient tasks.

Capacity must account for leave, meetings, support work, defects and other obligations. A simple capacity estimate is:

This is only a planning approximation. “Productive hours” excludes time unavailable for project work and should not be interpreted as a demand for continuous coding. Historical throughput is often more useful than theoretical hours when work items vary in size.

Teams should avoid filling all apparent capacity. A small reserve helps absorb defects, integration problems and urgent support. Work should be sliced vertically where possible so that each iteration produces a tested increment across relevant layers rather than incomplete layers of a large feature.

A strong iteration plan includes:

1. an iteration goal;
2. a prioritized and refined work set;
3. explicit dependencies and risks;
4. acceptance criteria and test responsibilities;
5. a definition of done, including documentation and security checks; and
6. a review and retrospective date.

The plan is inspected during daily coordination and adapted when evidence changes. Adaptation is disciplined change, not uncontrolled scope expansion.

5. Release Planning and Roadmaps

Release planning connects product value, technical feasibility and organizational commitments. A release may be internal, pilot, limited availability or general availability. Each type requires appropriate quality, support and governance controls.

A release roadmap is a high-level view of outcomes over time. It may show themes, capabilities, target windows, dependencies, risks and decision points. A roadmap should communicate direction and intent; it should not imply that uncertain future features have guaranteed dates.

Release selection should consider:

• customer and business value;
• regulatory, contractual or market deadlines;
• technical dependencies and architectural risk;
• team capacity and specialist availability;
• quality, security, privacy and accessibility readiness;
• operational support and deployment capability; and
• learning objectives, such as validating a risky assumption early.

A release candidate should pass explicit readiness criteria. Typical criteria include completed acceptance tests, acceptable defect levels, security and privacy checks, monitoring, rollback capability, documentation, support readiness and stakeholder approval. “Code complete” is not equivalent to “ready to release.”

Feature flags, canary releases and progressive delivery can reduce exposure by separating deployment from user availability. They do not eliminate the need for testing, governance or rollback planning.

6. Tools and Information Management

Tools such as Jira, Azure DevOps, GitLab, Microsoft Project, ProjectLibre and spreadsheet systems can support scheduling. The tool is less important than the quality of the underlying information. A tool should provide a shared work hierarchy, dependency visibility, ownership, dates, status history, reporting and access control.

A practical tool workflow is:

1. create the product or project hierarchy;
2. decompose approved scope into manageable work items;
3. record estimates, owners, dependencies and acceptance criteria;
4. generate the network or timeline view;
5. identify milestones and baseline the approved plan;
6. link development, test and deployment evidence where possible;
7. review actual progress and forecast completion; and
8. record decisions, changes and lessons learned.

Automatic percentage-complete fields can be misleading. A task that is “90% complete” for three weeks may hide an unresolved integration problem. Evidence-based status—such as accepted tests, reviewed code or deployed increments—is more reliable.

7. Illustrative Case: Campus Assessment Platform

Background

A college plans a web platform through which lecturers create assessments, students submit work and markers provide feedback. The first release must support submission and feedback before the next academic term.

Problem

The initial plan placed all development tasks in parallel and announced a fixed release date. Analysis revealed that identity integration depended on an external team, accessibility testing had not been scheduled, and the support team had no deployment runbook.

Analysis

The project team created a WBS and a dependency network. Requirements approval preceded detailed design. Identity integration and the submission workflow were identified as high-risk activities. Testing, accessibility review, data protection review, training and rollback preparation were added as explicit work. The team also distinguished an internal pilot from general availability.

Approach and solution

The roadmap was divided into three increments:

The team used a baseline for the approved pilot schedule, while maintaining a separate risk register. Each iteration had a goal and definition of done. A feature flag allowed the submission function to be enabled for pilot classes without exposing unfinished feedback functions to all users.

Outcome

The pilot began on the planned decision window, although one lower-priority reporting feature moved to a later release. Because the roadmap separated essential outcomes from optional scope, the change did not conceal a quality problem. The deployment runbook and monitoring reduced operational risk, and pilot feedback led to improved accessibility before general release.

Learning points

The case illustrates that scheduling is a coordination and risk-management activity, not merely a date-setting exercise. Explicit dependencies reveal hidden work. Release criteria protect users. Roadmaps support communication, while iteration plans support near-term execution. Separating a baseline from a living forecast preserves both accountability and adaptability.

8. Challenges, Governance and Ethical Practice

Common scheduling problems include optimistic estimates, omitted testing, hidden dependencies, multitasking, unstable priorities, excessive administrative detail and pressure to report green status. Managers should distinguish a forecast from a commitment and should communicate uncertainty honestly.

Scheduling data may also expose individual performance, leave, health information or workload patterns. Access should follow least-privilege principles, and reports should focus on team outcomes rather than encouraging harmful ranking of individuals. A schedule must never be used to justify unsafe workloads, unpaid excessive hours or discriminatory allocation of opportunities.

Governance should define who approves baselines, who accepts scope changes, who may authorize a release and what evidence is required. Regulated or safety-sensitive software may require formal traceability from requirements through tests and approval records. Privacy, security, accessibility and records-retention obligations should be included in the schedule rather than treated as optional final checks.

9. Contemporary Practice and AI Support

Modern delivery increasingly uses continuous integration, continuous delivery, infrastructure as code, automated testing and observability. These practices shorten feedback cycles but do not make planning unnecessary. They shift planning toward small increments, flow constraints, operational readiness and measurable product outcomes.

AI tools can summarize work items, identify possible dependency conflicts, suggest task decomposition or forecast trends from historical data. Their outputs require human review because training data may be incomplete, estimates may encode organizational bias, and generated plans may omit security, accessibility or regulatory work. Project teams should not enter confidential customer or employee information into an AI service without authorization. AI-generated schedules must be treated as proposals, with assumptions and evidence made visible.

Best Practices Checklist

• Begin with a clear WBS and definition of done.
• Record every important dependency, assumption and external constraint.
• Use network analysis to understand sequence and Gantt views to communicate timing.
• Identify critical and near-critical paths, not only the single longest path.
• Baseline approved plans and retain change history.
• Plan testing, security, accessibility, documentation and operations explicitly.
• Reserve capacity for defects, support and uncertainty.
• Use milestones for decisions and verifiable outcomes.
• Treat release readiness as evidence-based, not as a date alone.
• Review forecasts frequently and communicate uncertainty honestly.

Chapter Summary

Scheduling transforms software scope into sequenced, owned and time-related work. Work breakdown structures support decomposition; dependencies express logical, resource and external constraints; network diagrams show relationships; and Gantt charts communicate timing. Forward and backward passes provide early and late dates, while total float helps identify critical paths, subject to assumptions about duration and resources.

Milestones mark significant outcomes, and baselines provide approved references for controlling change. Iteration plans organize short-horizon delivery around goals, capacity and a definition of done. Release roadmaps connect product value with technical feasibility, quality, operational readiness and risk. Effective planning uses tools as shared information systems, not as substitutes for judgment. Ethical and professional scheduling requires honest uncertainty, responsible workloads, privacy protection and evidence-based release decisions.

Key Terms

Work breakdown structure: Hierarchical decomposition of project scope into manageable work.

Activity: A schedulable unit of work with a start and finish.

Dependency: A relationship constraining the order or timing of activities.

Finish-to-start: A dependency in which one activity must finish before another starts.

Milestone: A zero-duration marker for an important event, decision or outcome.

Gantt chart: A time-scaled chart showing activities, durations and often dependencies.

Network diagram: A graphical representation of activities and their logical relationships.

Forward pass: Calculation of earliest possible activity dates.

Backward pass: Calculation of latest permissible activity dates.

Critical path: The zero-float path determining the shortest completion time under stated assumptions.

Total float: Time an activity can be delayed without delaying planned project completion.

Baseline: An approved reference plan used to assess change and variance.

Iteration: A time-bounded cycle producing an integrated increment.

Release: A version made available to users or an operational environment.

Roadmap: A high-level view of intended product outcomes and timing.

Capacity: The realistically available work capability of a team during a period.

Definition of done: Shared criteria for considering work complete.

Feature flag: A control that separates deployment of code from exposure to users.

Progressive delivery: Gradual exposure of a release to users or environments.

Schedule variance: Difference between actual or forecast timing and a baseline.

Review Questions

Short Answer Questions

1. What is the difference between effort and duration?
2. Define a milestone and give one software-project example.
3. What does total float measure?
4. Why should testing and deployment be represented in a schedule?
5. What is the purpose of a schedule baseline?

Long Answer Questions

1. Explain how a work breakdown structure can be transformed into a dependency network and Gantt chart.
2. Describe the forward-pass and backward-pass methods used in critical-path analysis.
3. Compare an iteration plan with a release roadmap.
4. Discuss the assumptions and limitations of critical-path analysis.
5. Explain how release-readiness criteria improve software quality and governance.

Analytical / Application Questions

1. A project contains requirements analysis, design, implementation, integration testing and user acceptance testing. Propose reasonable dependencies, identify likely milestones and explain which activities should be monitored most closely.
2. A team has a fixed release date but an external identity service is delayed. Analyse at least three possible responses using scope, risk, quality and dependency considerations.
3. Design a two-iteration release plan for a small student-record system. State the iteration goals, capacity assumptions, acceptance evidence, risks and criteria for progressing to release.

Multiple Choice Questions with Answers

Question 1

Which relationship means that Activity B cannot start until Activity A has finished?

A. Start-to-start

B. Finish-to-start

C. Finish-to-finish

D. Start-to-finish

Correct Answer: B. Finish-to-start

Question 2

In a forward pass, the earliest start of an activity with several predecessors is normally the:

A. Smallest predecessor earliest finish

B. Average predecessor duration

C. Greatest predecessor earliest finish

D. Latest project completion date

Correct Answer: C. Greatest predecessor earliest finish

Question 3

An activity has ES = 6, EF = 10, LS = 8 and LF = 12. What is its total float?

A. 2 working days

B. 4 working days

C. 6 working days

D. 18 working days

Correct Answer: A. 2 working days

Question 4

Which item is most appropriate as a milestone?

A. Write 20 lines of code

B. Attend a routine meeting

C. Architecture approved

D. Open the project tool

Correct Answer: C. Architecture approved

Question 5

What is the primary purpose of a schedule baseline?

A. To prevent all future changes

B. To provide an approved reference for comparison

C. To replace the product backlog

D. To guarantee the original completion date

Correct Answer: B. To provide an approved reference for comparison

Question 6

Which statement best distinguishes a release roadmap from an iteration plan?

A. A roadmap concerns outcomes over a broader horizon, while an iteration plan concerns a short delivery cycle

B. A roadmap contains only coding tasks, while an iteration plan contains only tests

C. A roadmap is always fixed, while an iteration plan cannot change

D. They are identical terms for the same document

Correct Answer: A. A roadmap concerns outcomes over a broader horizon, while an iteration plan concerns a short delivery cycle

Question 7

A project has activities lasting 3, 4, 5, 3 and 2 working days on its controlling path. What is the path duration?

A. 12 working days

B. 15 working days

C. 17 working days

D. 20 working days

Correct Answer: C. 17 working days

Question 8

Which is the strongest evidence that a feature is ready for release?

A. The developer reports that coding is complete

B. The task is marked 100% complete

C. The feature passes agreed quality, acceptance and operational-readiness criteria

D. The feature appears on the roadmap

Correct Answer: C. The feature passes agreed quality, acceptance and operational-readiness criteria

Question 9

Why can adding people fail to shorten a software activity?

A. Software activities never require collaboration

B. Coordination overhead and sequential constraints may increase

C. Additional people always reduce quality to zero

D. Project tools prohibit resource changes

Correct Answer: B. Coordination overhead and sequential constraints may increase

Question 10

Which practice is ethically appropriate when using AI to support scheduling?

A. Accept every generated estimate without review

B. Upload confidential employee data to any public AI service

C. Treat AI output as a proposal and verify assumptions and risks

D. Use AI forecasts to rank individuals publicly

Correct Answer: C. Treat AI output as a proposal and verify assumptions and risks