In the previous chapter, we estimated the total number of days (or iterations) to complete the project. This assumed that each team member worked full-time on the project and at 100% productivity. In this section, we ask the question – is this reasonable?

You will likely work some variation on the 9 to 5 schedule for most jobs. The point is that you will be expected to work a roughly 8-hour day, with time allotted for breaks and lunch. Ignoring these breaks, will you spend every second of every minute of every day sitting in front of your computer working on code?

The answer is no. Distractions (e.g., meetings, administrative work) mean you won’t spend every moment coding. And even if your only distraction is a 10-minute stand-up meeting, you still have lost those 10 minutes to coding.

None of these distractions are necessarily a bad thing, they are just a reality of a job. And this reality suggests it is unlikely we will ever spend 8 hours coding. Assuming you have a 30-minute lunch and two 15-minute breaks per day, plus a daily 10-minute stand-up meeting, and only 2 hours of scheduled meetings per week, development time is reduced to 6 hours and 26 minutes each day. That’s slightly more than 80% of your time.

This doesn’t include the time it takes to catch up on emails or other interoffice communication. It doesn’t include unexpected visits by colleagues who may need something. It doesn’t include the time it takes you to get going in the morning. It doesn’t include the time to refill your tea or coffee between breaks. And it doesn’t include the time associated with office team building activities.

Many things are competing for your time.

And we still haven’t considered the human factor. There is no way that each of us is at 100% every single day. Family life, lack of sleep, as well as mental and physical health issues all have an impact on our ability to work at 100%. And even if all of those things are in check, there are some days when our minds are anywhere but at work. These things happen, and they need to be considered when we plan.

But how do we do this?

Velocity

While we can’t necessarily account for everything that might take away our time to implement our solution, we can build our production timeline in a way that buffers us against them. We do this using velocity.

Velocity is a measure of team productivity. It is specific to the team and is affected by many external factors. Regardless, a typical guideline is to set a team velocity to 70% when planning. This does not mean the team always works at this level, but it’s a good benchmark to evaluate development.

Why 70%? Lunches, breaks, and meetings leave a person with slightly more than 80% of their time to code. A 70% velocity would give each person an extra 48 minutes daily to address unexpected interruptions, and family/health/other commitments. That doesn’t mean that your boss wants you to slack off for that time, but it does provide them with a reasonably good estimate of productive development time.

Velocity isn’t just used for planning purposes. It is also used to ensure that productivity is on track. This will be described further below, and put into action when we get to Burn Down Charts later.

Productive Working Days

While a velocity of 70% is used to build a development timeline, it is also used to keep you on track. Velocity can let you know if your team is lagging or developing quicker than planned. And while the latter might seem like a good thing, it could also indicate that things are being overlooked and not critically assessed.

But how do we calculate velocity?

We must understand the difference between productive and regular time to calculate velocity. In particular, productive working days and working days (although the following would hold for productive working hours and working hours).

A full-time regular employee would have five working days. But as we have seen, it’s unlikely that every moment of these five working days is spent productively coding. Our velocity suggests that you would have only 70% of your time to code.

For every full-time week, you have to offer your employer (given a velocity of 70%), you are only expected to produce 3.5 days of work.

What does this mean for your production timeline? It means that the estimated length of production that you would have calculated at the end of the last chapter is underestimated. If the time to implement the requirements was 100 days (that is, you require 100 productive days to complete the project), a velocity of 70% would imply that you’d need almost 143 working days to complete the project.

In other words, you would need more than 6 full-time weeks to deal with meetings, lunches, breaks, and such!

Of course, you likely won’t be coding on your own. Building our timeline requires us to consider the team’s size. This is a straightforward calculation.

• The total number of working days per team is determined by multiplying the number of team members by the number of working days per team member.
• The total number of productive working days per team is determined by multiplying the number of team members by the number of productive days per team member, or by multiplying the total number of working days per team by the velocity.

While you may not be in charge of a team, you must be able to make these types of calculations. Further, you should be able to manipulate the relationships to determine, for example, your team’s current velocity, or the number of working days associated with a project given the velocity and productive working days.

Fortunately, the velocity triangle is a helpful tool.

To use the triangle, cover up any of the three elements you are trying to calculate. The remaining two will be used to make the calculation. If two elements are separated by a horizontal line, then the top is divided by the bottom. If two elements are separated by a vertical line, then the left is multiplied by the right.

Activity: Working With The Velocity Triangle

Given a team of 5 people working full time on a project, how many productive working days per iteration does the team have if their velocity is 75%?

If the total number of productive days required to implement every requirement was estimated to be 500, how many weeks would it take a team of 5 full-time employees working at 80% velocity to completely implement the project?

If a team of four has implemented 30 requirements were estimated to take 120 productive days to complete, but they completed them in 4 full-time weeks (i.e. 20 days), what is their velocity?

If an iteration is expected to be 20 working days long, and you have a team of 10 people, how many productive working days do you have available if the velocity is 90%?

If your project is expected to take 280 productive working days to complete, but only 20 working days to implement, how many people would you need on your team if they were expected to have a velocity of 70%?

True or false? A team of with a velocity of 60% will require more time to complete a project than a team of 3 with a velocity of 80%.

Review Questions

Solutions

Assuming an iteration has 20 working days, each person can offer 20×0.75=15 productive working days per iteration to implement the solution. Since there are five team members, the team will have 5×15=75 productive working days per iteration.

For each week, a single employee working at 80% velocity is expected to offer 5×0.8=4 productive working days. A team of five will therefore have 5×4=20 productive working days to contribute to the project. Since there are 500 productive working days of effort required, the total project is expected to take 500/20=25 weeks.

A team of four has completed 120 productive working days of code in 20 days. On average, each person completed 120/4=30 productive working days of code in 20 days. The velocity is therefore 30/20=1.5 (or 150%).

Each person is expected to contribute 20×0.9=18 days of productive working days per iteration. A team of 10 people is expected to complete 10×18=180 productive working days per iteration.

In 20 working days, a person working at a velocity of 70% is expected to produce 20×0.7=14 productive working days. To complete 280 productive working days of work in the same time, a team would require 280/14=20 team members.

A team of 4 with a velocity of 60% will have 4×0.6×20=48 productive working days in a standard 20-day iteration period. A team of 3 with a velocity of 80% will have 3×0.8×20=48 productive working days in a standard 20-day iteration period. Therefore, the statement is false.