Up to this point, we have spent a great deal of time understanding the problem before thinking about the solution. We have:

• Written requirements;
• Categorized them using the MuSCoW Method;
• Assigned priorities;
• Identified dependencies; and
• Estimated the time needed to implement each requirement.

All of this work has been preparing us for one important question: How do we turn this list of requirements into a realistic development plan? The answer is by building a production timeline.

A production timeline helps us organize work into manageable pieces, coordinate the efforts of multiple developers, and communicate progress to clients throughout the project.

Three New Terms

Before building a timeline, there are three concepts we need to understand:

• Iterations
• Milestones
• Timelines

Although these terms are closely related, they describe different parts of the development process.

Iterations

An iteration is a short period of development during which a team completes a set of requirements.

Rather than attempting to build an entire system before receiving feedback, software teams divide projects into smaller pieces.

Each iteration has a clear goal and produces a working improvement to the software.

The length of an iteration varies across organizations, but many teams work in iterations of approximately four weeks (about 20 working days).

Working in shorter iterations provides several advantages:

• Progress becomes easier to measure.
• Clients can provide feedback more frequently.
• Problems are identified earlier.
• Teams can adjust plans before investing too much time in the wrong direction.

Iterations encourage continuous improvement rather than one large delivery at the end of a project.

Milestones

A milestone represents a significant point in the project.

Unlike an iteration, which is simply a period of work, a milestone marks the completion of an important objective.

Milestones often correspond to software releases or major demonstrations.

For example, a project might include milestones such as:

• Version 1.0
• Beta Release
• Public Launch

A milestone is an opportunity to evaluate progress, celebrate accomplishments, and decide what comes next.

Timelines

A timeline brings everything together.

A timeline is the complete sequence of iterations, milestones, and development activities required to deliver the project.

It answers questions such as:

• What work will be completed first?
• Who will complete it?
• When should it be completed?
• When will the client receive updates?
• When are major releases expected?

A timeline transforms a collection of individual requirements into a coordinated development plan.

Planning For One Developer

Imagine you are the only person working on a project.

Planning is relatively straightforward.

You simply schedule requirements one after another while ensuring that dependencies are respected.

Requirements that have no dependencies can be completed first.

Requirements that depend on earlier work are scheduled later.

Although this process still requires planning, it is generally easy to understand because only one person is completing the work.

Planning For A Team

Most software projects involve more than one developer.

As soon as multiple people begin working together, planning becomes much more challenging.

Some requirements can be implemented simultaneously.

Others must wait until prerequisite work has been completed.

As a result, team members will not always be busy at the same time.

Imagine that one developer is responsible for creating user accounts.

Another developer cannot begin implementing profile editing until those accounts exist.

During that time, the second developer may need to work on a completely different requirement—or may briefly have no suitable work available.

These temporary gaps are a normal consequence of dependencies.

They are not necessarily signs of poor planning.

Instead, they reflect the logical structure of the software being developed.

Building A Practical Timeline

As you begin creating timelines, keep the following guidelines in mind.

Break Large Requirements Into Smaller Pieces

If a single requirement is estimated to require approximately 15 working days or more, it is usually too large.

Large requirements are difficult to estimate accurately, difficult to monitor, and difficult to complete within a single iteration.

Breaking them into smaller requirements generally produces a more flexible and manageable development plan.

End Every Iteration With Client Feedback

Each iteration should conclude with an opportunity to meet with the client or users.

This may involve:

• Demonstrating completed functionality;
• Gathering feedback;
• Confirming requirements;
• Discussing changing priorities; or
• Revising future plans.

Remember that software development is an iterative process.

The timeline should evolve as the project evolves.

If the team finishes earlier than expected—or encounters unexpected challenges—the timeline should be updated in consultation with the client.

A timeline is a planning tool, not a contract that can never change.

Assign One Developer Per Requirement

In reality, multiple developers can sometimes work on the same requirement simultaneously.

However, for planning purposes in CIS3750, we make a simplifying assumption:

One developer implements one requirement at a time.

Although this produces a more conservative timeline, it also avoids many coordination problems and makes planning much easier.

Later in your software careers, you will encounter techniques that support parallel development within individual requirements.

For now, this assumption helps us focus on the fundamentals of project planning.

Estimating Project Duration

Once every requirement has a time estimate, we can begin estimating the overall duration of the project.

A simple starting point is:

1. Add together the estimated time for every requirement.
2. Divide by the number of developers.

This provides an optimistic estimate of the total development effort.

For example, if a project contains 120 developer-days of work and four developers are available, the optimistic estimate is approximately 30 working days.

Estimating The Number Of Iterations

After estimating the total duration, we can estimate the number of iterations.

Suppose each iteration lasts 20 working days.

A project estimated at 30 working days would require approximately one and a half iterations.

In practice, this would likely be planned as two iterations.

This calculation provides an initial planning estimate rather than an exact schedule.

Why Simple Estimates Are Optimistic

The calculations above assume that every developer can work continuously throughout the project.

In practice, this rarely happens.

Dependencies often create periods where developers must wait for prerequisite work to be completed before beginning their own tasks.

These unavoidable gaps reduce the team’s overall efficiency.

Similarly, no team spends every hour writing code.

Time is also required for:

• Meetings;
• Design discussions;
• Testing;
• Documentation;
• Bug fixes;
• Code reviews; and
• Client communication.

As a result, the simple calculations above usually underestimate the true duration of a project.

Looking Ahead

In this chapter, we learned how requirements, dependencies, and time estimates come together to form a production timeline.

However, one important question remains.

How productive is a software development team in practice?

The answer is almost never 100%.

In the next chapter, we will examine team productivity and explore why realistic project schedules must account for the many activities that occur beyond writing code.