In the previous chapter, we learned how to estimate the length of a project by using requirements, time estimates, team size, iterations, and milestones.

However, those first estimates usually make one unrealistic assumption: Everyone on the team is working on the project at 100% productivity.

In real life, this almost never happens.

Even if you are working a full-time job, you will not spend every minute of every day writing code.

The Reality of a Workday

Many full-time jobs are built around a standard workday of roughly eight hours.

At first, it might seem reasonable to assume that an eight-hour workday provides eight hours of development time.

But think about a typical day.

Time may be spent on:

• Lunch and breaks;
• Stand-up meetings;
• Team meetings;
• Email and messages;
• Administrative tasks;
• Client communication;
• Planning and documentation;
• Helping teammates; and
• Switching between tasks.

None of these activities are necessarily bad.

In fact, many of them are essential to good software development.

However, they reduce the amount of time available for implementation.

For example, suppose each day includes:

• A 30-minute lunch;
• Two 15-minute breaks;
• A 10-minute stand-up meeting; and
• Two hours of scheduled meetings per week.

Even before considering email, interruptions, or unexpected work, this leaves approximately 6 hours and 26 minutes per day for development.

That is slightly more than 80% of an eight-hour day.

The Human Factor

There is another reality we need to consider.

People are not machines.

No one works at exactly the same level every day.

Sleep, health, stress, family responsibilities, motivation, and unexpected life events all affect productivity.

Some days, you may work quickly and feel focused.

Other days, the same task may take much longer.

Good project planning recognizes this reality.

It does not assume that people can work at full capacity every moment of every day.

Introducing Velocity

To build more realistic timelines, software teams use the concept of velocity.

Velocity is a measure of productive development capacity.

In simple terms, velocity helps us estimate how much project work a team can realistically complete within a given amount of working time.

For planning purposes, a common guideline is to assume a velocity of approximately 70%.

This does not mean people are only trying 70% of the time.

It means that, after accounting for meetings, communication, breaks, interruptions, and ordinary human variation, about 70% of the available working time may realistically be available for productive development work.

Velocity helps us plan with a buffer.

It also helps us evaluate whether a team is progressing faster or slower than expected.

Productive Working Days Versus Working Days

To use velocity, we need to distinguish between two kinds of time:

• Working days
• Productive working days

A working day is a regular day at work.

A productive working day is the portion of that day that can realistically be spent completing development work.

For example, a full-time employee may work five days in a week.

If we assume a velocity of 70%, then:

5 working days × 0.70 = 3.5 productive working days

This means that, during a typical full-time week, one developer may contribute approximately 3.5 productive days of development work.

Why Velocity Changes The Timeline

Suppose your team estimates that a project requires 100 productive working days.

If you ignore velocity, you might assume the project requires 100 working days.

But if the team works at 70% velocity, the project will take longer.

To determine the required number of working days:

Productive working days ÷ velocity = working days

So:

100 ÷ 0.70 = 142.9 working days

In other words, completing 100 productive days of work requires approximately 143 working days at 70% velocity.

This is why early timeline estimates are often too optimistic.

They count the work but forget the reality of the workday.

Team Size And Velocity

Most projects involve more than one developer.

To calculate the team’s total working capacity, we need to consider both team size and velocity.

The total number of working days available to a team is:

Number of team members × working days per person

The total number of productive working days available to a team is:

Number of team members × working days per person × velocity

For example, suppose a team has four developers, each working for 20 working days, with a velocity of 70%.

The team has:

4 × 20 = 80 working days

But the team has only:

80 × 0.70 = 56 productive working days

This means the team should plan for approximately 56 days of development work during that iteration.

The Velocity Triangle

The relationship between working days, productive working days, and velocity can be summarized as follows:

Productive Working Days = Working Days × Velocity

From this relationship, we can calculate any missing value.

To calculate productive working days:

Working Days × Velocity

To calculate working days:

Productive Working Days ÷ Velocity

To calculate velocity:

Productive Working Days ÷ Working Days

This is sometimes represented as a triangle:

Using Velocity Carefully

Velocity is useful, but it should not be treated as a perfect measure.

A team with a high velocity is not automatically a better team.

A team with a lower velocity is not automatically a worse team.

Velocity is affected by many factors, including:

• Project complexity;
• Team experience;
• Communication needs;
• Technical uncertainty;
• Testing requirements;
• Documentation expectations; and
• Client involvement.

A surprisingly high velocity may also be a warning sign.

It could mean that the team is moving efficiently.

But it could also mean that testing, documentation, accessibility, security, or client feedback are being overlooked.

Velocity should support reflection, not replace judgment.

Why Velocity Matters in CIS3750

In CIS3750, velocity helps us create more realistic development timelines.

It reminds us that software development includes more than coding.

Teams need time to communicate, plan, test, document, revise, and respond to feedback.

If we ignore these activities, our timelines will almost always be too optimistic.

Good planning recognizes that people are human, projects are complex, and productive time is limited.

Velocity gives us a way to plan with that reality in mind.

Activity: Working with Velocity

Use the velocity formulas to answer the following questions.

Question 1

Given a team of 5 people working full time on a project, how many productive working days per iteration does the team have if:

• Each iteration is 20 working days; and
• The team’s velocity is 75%?

Question 2

If a project requires 500 productive working days, how many weeks would it take a team of 5 full-time employees working at 80% velocity to complete the project?

Question 3

A team of 4 completed requirements estimated at 120 productive working days in 4 full-time weeks.

What was the team’s velocity?

Question 4

If an iteration is 20 working days long, and a team has 10 people, how many productive working days are available if the team’s velocity is 90%?

Question 5

A project is expected to require 280 productive working days.

If the project must be completed in 20 working days, how many people are needed on the team if the expected velocity is 70%?

Question 6

True or false?

A team of 4 with a velocity of 60% will require more time to complete a project than a team of 3 with a velocity of 80%.

Solutions

Solution 1

Each person contributes:

20 × 0.75 = 15 productive working days

With 5 team members:

5 × 15 = 75 productive working days

The team has 75 productive working days per iteration.

Solution 2

Each person contributes:

5 × 0.80 = 4 productive working days per week

With 5 team members:

5 × 4 = 20 productive working days per week

The project requires:

500 ÷ 20 = 25 weeks

The project would take 25 weeks.

Solution 3

The team completed 120 productive working days in 20 working days.

The team had:

4 × 20 = 80 working days

Velocity is:

120 ÷ 80 = 1.5

The team’s velocity was 150%.

This is unusually high and should prompt discussion. It may mean the original estimates were too large, the team worked beyond normal expectations, or some work was not completed as expected.

Solution 4

Each person contributes:

20 × 0.90 = 18 productive working days

With 10 team members:

10 × 18 = 180 productive working days

The team has 180 productive working days available.

Solution 5

Each person contributes:

20 × 0.70 = 14 productive working days

The number of people required is:

280 ÷ 14 = 20

The project would require 20 people.

Solution 6

A team of 4 at 60% velocity over 20 working days produces:

4 × 20 × 0.60 = 48 productive working days

A team of 3 at 80% velocity over 20 working days produces:

3 × 20 × 0.80 = 48 productive working days

Both teams produce the same amount of work.

The statement is false.