What's your velocity?

Posted on 9/06/2007 by Rajeev Singh

For the past couple of years I have been working in teams that measure their productivity and throughput using a term called "Velocity". For a team that is engaged in software development and delivery every story is estimated at certain points worth of effort that is required to complete the story. The sum total of points for an iteration's completed stories is the team's velocity.

It's all about Development

The velocity of a team is its development velocity. That means it only measures the throughput and productivity of the development effort. There are no measures of these parameters for the QA and BA teams. Some of the practical constraints are that these groups are not as insulated as the development group and neither as ideally served. By that I mean that the Development group in an iteration is bound by the time of two weeks to finish their effort and are provided the material (stories) to develop from. So it makes it easier to measure their velocity and the number reflects the nature of a very controlled environment. Business Analysts on the other hand don't have this controlled environment. They have to interact with users and business outside their immediate sphere of influence and control. So the Business Analysts are not bound by iteration length for analysis. They can take anywhere from 1-3 weeks to analyze a story. And it is true for the QA groups as well. So, the problem is that Business Analysts and QAs have no idea of their velocity.

Is that a problem. My answer would be, "it depends". As long as the development team has enough work to do with just the right inventory of stories on which they can stretch if they finish their work early, who cares. On the other hand, there are some who'd want to know their throughput. So, there has to be an indicator for Business Analysts as well. Estimating the Unknown The problem, however, is the concept itself. Velocity is computed from the estimates that are reflected by the developers based on the story details. In case of the Business Analysts, they don't have anything to estimate. They are in the business of creating something that can be estimated. So, the big question is, "How can the Business Analysts estimate their analysis"? The second question is, "Should they even do it?".

1 Response to "What's your velocity?"

.
gravatar
Analysis Manager Says....

Hi Rajeev,

After reading "The Goal" by Eliyahu M. Goldratt, I have put some thought into how we might be able to measure the throughput of BAs.

The best thing that I was able to come up with was to measure the functional specification portion of the BA work. That is, once the requirements are known, how long does it take the BA to create the functional specs.

I have done this by using function points: counting how many function points exist in the newly created specification per time. It's not easy!

As I manager a large team of business systems analysts I'm always trying to come up with objective methods of measuring the performance and at least the relative productivity among the BAs.

Another way I thought of measuring is to log defects (bugs) against the functional specs and to measure the number of defects per function point. This would give me an idea of the quality of the specs created by one analyst relative to others.

Let me know if you make more inroads into this topic.

Best regards,
- Adrian