Building a good timeline requires more than placing requirements onto a calendar.

A timeline needs to balance several different pieces of information, including:

• Requirement categories;
• Requirement priorities;
• Requirement dependencies;
• Time estimates;
• Team size; and
• Team velocity.

In other words, a development timeline is where all of our earlier planning work comes together.

The goal is to create a realistic plan that shows when each requirement will be implemented, who will implement it, and how the work will move from one iteration to the next.

Consider the set of requirements illustrated here. We’ll use these to clarify some of the concepts in this chapter.

What We Need To Know First

Before building a timeline, we need to answer several questions.

For example:

• How many people are on the development team?
• What is the team’s expected velocity?
• How long is each iteration?
• Does the team work only during regular business hours?
• Does the team work on weekends?
• Can requirements and their dependencies be worked on at the same time?
• Are there any constraints that affect who can complete particular work?

In a professional setting, the answers to these questions depend on the organization, the team, the project, and the client.

In CIS3750, we simplify the process so that everyone can practice the same planning approach.

Timeline Rules For CIS3750

For this course, use the following assumptions unless told otherwise:

• Each team has 4 developers.
• Each developer works the same 9:00 AM to 5:00 PM schedule.
• The team does not work weekends.
• The team has a velocity of 80%.
• Each iteration is 10 working days.
• Team members may work in parallel when dependencies allow.
• Dependencies must be respected.
• A requirement and its dependencies cannot be developed at the same time.
• Each requirement is assigned to only one developer.
• Requirements cannot be split across iterations.

These assumptions are not meant to describe your actual weekly schedule as a student.

Instead, they give us a consistent structure for learning how to build development timelines.

Productive Time Per Iteration

Given these rules, we can calculate the productive working time available in each iteration.

Each iteration contains 10 working days. With a velocity of 80%, each developer has:

10 × 0.80 = 8 productive working days

Since the team has 4 developers, the team has:

4 × 8 = 32 productive working days

This means that, in one iteration, the team can schedule at most 32 productive days of development work.

This does not mean every timeline will use all 32 days.

Dependencies may create gaps. Some requirements may not fit neatly. Some developers may have unused time.

A good timeline tries to use the team’s time well while still respecting the logic of the project.

How To Begin Building A Timeline

Start with the first requirement in your sorted and renumbered list.

This requirement should appear early because it has a high category, high priority, and no unresolved dependencies.

Assign it to the first available developer at the earliest available time.

Then move to the next requirement.

For each requirement, ask:

• Have all dependencies already been completed?
• Is there enough productive time available in the current iteration?
• Can the requirement fit without being split across iterations?
• Which developer should complete the work?

If the requirement fits, place it in the timeline. If it does not fit, move it to the next appropriate place in the timeline.

This process continues until all requirements have been scheduled or until the current iteration is full.

Respecting Dependencies

Dependencies determine when a requirement can begin.

If Requirement 2 depends on Requirement 1, then Requirement 2 cannot begin until Requirement 1 has been completed.

Requirement 2 may be assigned to the same developer as Requirement 1, or it may be assigned to a different developer.

What matters is that Requirement 1 is finished first.

For example, suppose Requirement 1 takes one day and Requirement 2 takes two days.

If Requirement 1 is completed on Day 1, then Requirement 2 can begin on Day 2.

It cannot begin on Day 1, because the dependency has not yet been satisfied.

Building The Timeline Is Like Tetris

As you schedule requirements, you will often feel like you are playing Tetris.

You are trying to fit requirements into available spaces while respecting:

• Time estimates;
• Dependencies;
• Developer availability;
• Iteration boundaries; and
• Productive working time.

There may be more than one valid timeline.

One team might assign a dependent requirement to the same developer.

Another team might assign it to a different developer.

Both timelines may be valid if they respect the rules.

The goal is not to find the only correct answer.

The goal is to create a timeline that is logical, realistic, and defensible.

When Requirements Do Not Fit

Sometimes a requirement will not fit into the available time.

This may happen because:

• The requirement is too large;
• Its dependencies are completed too late;
• The iteration does not have enough space remaining; or
• Assigning it would require splitting it across iterations.

In these cases, the requirement should be moved to a later iteration.

If a requirement is so large that it cannot fit within a single iteration, it should be reviewed and likely broken into smaller requirements.

Large requirements are difficult to estimate, schedule, test, and demonstrate.

Smaller requirements are easier to manage.

Recording The Timeline In A Spreadsheet

For CIS3750, your timeline will be recorded in the provided spreadsheet template.

When entering requirements:

• Enter the requirement number in each cell the requirement occupies.
• Do not merge cells.
• Use integer values only.
• Ensure the number of cells matches the requirement’s time estimate.
• Ensure the requirement does not span multiple iterations.
• Ensure dependencies are completed before dependent requirements begin.

For example, if a requirement takes two productive days, and each day is represented by two half-day cells, then the requirement number should appear in four cells.

The spreadsheet should make the timeline easy to read and easy to evaluate.

Other Scheduling Considerations

Even when a timeline follows the rules, there may still be choices to make.

Same Developer Or Different Developer?

If Requirement 2 depends on Requirement 1, should the same developer complete both?

Sometimes this makes sense.

The developer who completed the first requirement may already understand the relevant code, assumptions, and design decisions.

This can reduce handoff time.

However, assigning related work to different developers can also be valuable.

A second developer may notice issues the first developer missed.

There is no universal answer.

The choice depends on the project, the team, and the risks involved.

Avoiding Awkward Breaks

You should also consider where work falls in the schedule.

For example, a requirement that begins late on Friday and continues Monday morning may technically fit.

However, the developer may need time on Monday to remember where they left off.

This does not mean work can never span a weekend in real life.

But when planning, it is worth considering whether certain schedules may reduce productivity.

A technically valid timeline is not always the most realistic timeline.

When Timelines Go Long

Even with careful planning, projects may take longer than expected.

This can happen for many reasons:

• Estimates were too optimistic.
• Dependencies were more complicated than expected.
• The team’s velocity was lower than planned.
• A team member became unavailable.
• New client needs emerged.
• Technical challenges appeared during development.

When this happens, many people immediately suggest adding more developers.

This may seem like a simple solution.

It usually is not.

Why Adding People May Not Help

Adding someone new to a project takes time.

A new team member must learn:

• The codebase;
• The requirements;
• The tools;
• The client context;
• The team’s workflow; and
• The design decisions already made.

During this learning period, existing team members may need to pause their own work to help.

As a result, adding people can temporarily reduce productivity rather than increase it.

Larger teams also require more communication and coordination.

More people does not automatically mean faster progress.

Why Overtime Is Risky

Another common response is to ask the team to work overtime.

This may help in the very short term, but it is rarely a good long-term solution.

Overtime can lead to:

• Stress;
• Burnout;
• Lower-quality work;
• More mistakes;
• Reduced motivation; and
• Lower velocity over time.

A healthy team is more likely to produce good software than an exhausted one.

A Better Response

When a timeline begins to go long, the best response is usually to pause, communicate, and reassess.

First, work with the team.

Ask:

• Are there specific roadblocks?
• Are there dependencies causing delays?
• Are the estimates still realistic?
• Are there requirements that need to be broken down?
• Is the team stuck on a technical issue that can be resolved?

Second, work with the client.

The client should be part of the conversation.

This may involve revisiting:

• Requirements;
• Priorities;
• Milestones;
• Scope;
• Timeline expectations; and
• Future releases.

Keeping the client informed builds trust.

It also helps the client make informed decisions about what is truly essential.

Sometimes the timeline must change.

Sometimes the scope must change.

Sometimes a lower-priority requirement must be delayed.

What matters is that these decisions are made thoughtfully and collaboratively.

Final Thought

A timeline is not simply a schedule.

It is a planning tool that helps the team think carefully about work, capacity, dependencies, and communication.

A good timeline does not guarantee that everything will go exactly as planned.

But it does help the team identify problems earlier, make better decisions, and communicate more clearly with the client.

In CIS3750, building a timeline is not about filling cells in a spreadsheet.

It is about learning how to turn requirements into a realistic, responsible, and collaborative development plan.