Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

Assuming similar work has been done in the past, can velocity be measured on a waterfall project? If that isn't the case, is there a more appropriate capacity management tool on a waterfall project?

share|improve this question
    
It is not an insight that could make an answer, but I suppose you should look into ideas of Lead an Cycle Time introduced in Kanban. Velocity is rather tightly related to a concept of short, repeating iterations which - I assume - is not a major property of a waterfall project. –  Bartosz Rakowski Dec 18 '12 at 8:48
    
Hi Superduperfly, welcome to PMSE! When you ask about 'velocity', you mean if it's possible to base the estimates for the current project based on previous (similar) projects? –  Tiago Cardoso Dec 18 '12 at 10:50
    
@Tiago Cardoso thank you. Yes, that is what I was getting at. –  superduperfly Dec 18 '12 at 12:46
    
I am not familiar with Lead and Cycle Times but I will look into them. Thank you @Bartosz Rakowski –  superduperfly Dec 18 '12 at 12:47
add comment

2 Answers 2

up vote 3 down vote accepted

Measuring Velocity

According to one source:

Velocity is measured in the same units as feature estimates, whether this is story points, days, ideal days, or hours that the Scrum team delivers - all of which are considered acceptable.

However, most sources don't really explain that velocity is based on the idea that you can extrapolate your expectations for velocity based on historical measures of how much level-of-effort can fit within a given time-box.

In addition, the level-of-effort estimates that create velocity metrics assume a baseline task size. For example, if task B is roughly 5 times harder than the baseline task A that's worth 1 story point, task B is assigned a story point value of 5.

Story points (or other level-of-effort estimates) are not quite the same thing as the throughput and batch-size measurements used in Kanban, but there are some similarities. Throughput may be easier to retroactively calculate than velocity simply because it is less dependent on the original level-of-effort estimates for task, which may not be tracked as such in a waterfall project.

Why Velocity/Throughput is a Bad Fit for Waterfall

A typical PMI-style project often has a work breakdown structure, but those tasks are rarely decomposed into tasks of a uniform size (needed for Kanban-style throughput estimates) or time-boxed multiples of a baseline level-of-effort (needed for Scrum-style velocity estimates). That would seem to make velocity per se a poor fit for waterfall-style development.

Retrofitting a Time-Box

You may be able to retrofit velocity estimates in a waterfall project by arbitrarily assigning time-boxes. For example, you might assume that every two calendar weeks is a time-box, and see how many man-hours of completed work fit into each time box as a trailing average.

This will be a very rough estimate, and you should probably expect the estimates that you get this way to vary by at least an order of magnitude unless your WBS is extremely granular. Whether or not this sort of retconned velocity estimate is in any way useful on a waterfall project (where you're generally tracking dependencies and deviations rather than throughput or time-boxed iterations) is up to you.

Deviations from Milestones

As an informal rule of thumb, most waterfall-style projects that I've worked on have used deviations from planned milestones as their primary metric. For example, if Feature Alpha is due June 1st, one tracks whether one is on-target for the June 1st delivery date or how far progress towards Feature Alpha is behind schedule. (Hint: Milestones are rarely ahead of schedule on waterfall projects.)

Accuracy with this sort of metric relies on a feedback loop that continually assesses the start/end dates of dependent tasks, and applying any identified deviations to the projected delivery date. This is a useful technique when one is tracking by time, but not so much when one wants to track the throughput of tasks or the velocity of features delivered.

As with any methodology, your mileage may vary.

share|improve this answer
add comment

You may want to use earned value management techniques. These should give you an idea of progress to date in comparison to the baseline plan and also allow you to extrapolate future progress. As with other forms of prediction, the accuracy of the estimates will improve as you get closer to the end of your project.

The main problem that I have had with EVM in the past is trying to avoid having Accounting take it over to suit their purposes rather than suit the purposes of the project.

share|improve this answer
    
wow, I really like this concept. Thank you! –  superduperfly Dec 19 '12 at 2:40
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.