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

For most jobs, you will likely be required to work some minor variation on the 9 to 5 schedule. 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?

More than likely, the answer to this is no. Between scheduled meetings, and random people dropping by because you might be able to offer them advice, administrative duties, and a variety of other activities, you’re not going to spend every moment developing the project you have been assigned. And even if your only distraction from work 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 the workforce. And this reality suggests it is very unlikely that we will ever spend 8 hours developing. In fact, 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, the total amount of time you have to develop per day is reduced to 6 hours and 26 minutes. That’s slightly more than 80% of your time.

This doesn’t include the time it takes to catch up on emails, or Slack messages (or any other form of communication that might be popular where you work). This also doesn’t include the random and unexpected visits by your 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 it takes to refill your tea or coffee between breaks. And it doesn’t include the time that might be associated with office team building activities.

The bottom line, there are a huge number of things competing for your time.

And we still haven’t considered the human factor. That is, 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 just some of those 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 a lot of outside sources. Regardless, a typical guideline is to set a team velocity to 70% when one is planning how to implement a solution. This does not mean that the team is actually working at this level at all times, but it’s a good benchmark to evaluate development.

Why 70%? If you consider that lunches, breaks, stand-up meetings, and other meetings leave a person with slightly more than 80% of their time to code, a 70% velocity will 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. Beyond being used to help build your development timeline, 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 in this chapter.

Productive Working Days

While a velocity of 70% is used to build a development timeline, it is also used to keep you on track. That is, velocity can be used to let you know if your team is lagging behind what is expected of them, or if they are developing far more quickly 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?

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

In a typical week, a full-time regular employee would have five working days that could be assigned to any job. But as we have seen, it’s unlikely that every moment of these five working days is spent productively coding. In fact, our velocity suggests that you would have only 70% of your time to code.

That is, for every full-time week of work you have to offer your employer, and assuming a velocity of 70%, you are only expected to offer 3.5 productive working days to the project.

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 definitely underestimated. In fact, if the time required to implement the requirements was calculated to be 100 days (that is, you require 100 productive days to complete the project), a velocity of 70% would imply that you’d actually 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. This means that building our timeline also requires us to consider the size of the team we have. 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, it’s important that you are 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, there is a simple tool that can be used to help you do this. It is known as the velocity triangle (and might look familiar to you if you’ve taken a math or physics course that used a similar tool to relate velocity, distance, and time).

To use the triangle, simply cover up any of the three elements you are trying to calculate. The remaining two elements of the triangle will be used to make the calculation. If the two elements are separated by a horizontal line, then the top is divided by the bottom. If the 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 that 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 will be able to 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, this means that 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 of work. 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.