Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Projecting Velocity is Useless

How do you measure velocity?
Based on number of functionally tested features deployed OR based on number of estimated story points (or whatever your estimation unit is) that were completed in a time box?

If you are using story points (Nebulous Units of Times {NUTS}), then I don’t think projecting your velocity and drawing conclusions based on the projection makes any sense. Because:

  • you are tracking against what you thought at point X in time. And lots of things have changed since then.
  • this method makes a fundamental assumption that the % error in all your estimates is approximately same. If we are 10% behind schedule, we’ll stay 10% behind schedule as far as we develop things at this rate. Personally I don’t think this holds good. Because your estimation errors vary across your estimates.

In my experience velocity is not a straight line, its filled with curves. As the project progresses, you don’t necessarily have a linear velocity. Estimates make you believe that its linear. In fact what I’ve seen is that the velocity seems to slow down and pick up. One needs to regularly invest in paying off the technical debt and then they see the velocity go up again. There are also other reasons why your velocity will vary and won’t follow a straight line. So projecting a line based on your velocity might be misleading.

By looking at the progress without making any explicit projection, a team can get an impression of how the project is doing. Usually I try to do a breadth-first approach of all the important features. What this means is that I don’t have a feature fully 100% ready while others are 0% complete. I work on the very basic needs of all the top most priority features and later add more sophistication as needed. This gives me a big advantage. Now I don’t just vary scope by adding or removing entire feature, but I can also vary scope by increasing or reducing the sophistication levels of different feature.

This approach in my experience reduces a lot of delivery and expectations related risk. If this approach is followed, in the worst case, on the day of delivery, I’ll have, if not all, most features available with varying sophistication instead of varying internal quality. Best case I have the right set of features (without any extra/useless features) fully functional ahead of the promised time.

  • Mark Stijnman

    I don’t really disagree with you, but how does this approach differ from splitting your stories into smaller stories? You could easily make one story for the basic functionality, that gets a high priority, and then more stories for every extra level of sophistication, with ever decreasing priority. Wouldn’t that achieve the same goals, while at the same time being able to plan and track and communicate your progress better?

  • Mark Stijnman

    I don’t really disagree with you, but how does this approach differ from splitting your stories into smaller stories? You could easily make one story for the basic functionality, that gets a high priority, and then more stories for every extra level of sophistication, with ever decreasing priority. Wouldn’t that achieve the same goals, while at the same time being able to plan and track and communicate your progress better?

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    How does this approach differ from splitting your stories into smaller stories?

    This could be one way to implement this. However there are some issues with this approach:

    You’ll have an extra overhead of managing stories (its funny you look at this as better planning and tracking and I look at it as overhead)
    Some times (not always) these thin-slices are technical tasks which make no sense or are noise to the customer. User Stories loose their meaning then
    I hope you are saying that you’ll thin slice the stories JIT and not upfront. Else it might lead to pre-mature analysis and slicing. Some thin-slicing can be done before hand, but in lot of cases thin slices happen during development

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    How does this approach differ from splitting your stories into smaller stories?

    This could be one way to implement this. However there are some issues with this approach:

    • You’ll have an extra overhead of managing stories (its funny you look at this as better planning and tracking and I look at it as overhead)
    • Some times (not always) these thin-slices are technical tasks which make no sense or are noise to the customer. User Stories loose their meaning then
    • I hope you are saying that you’ll thin slice the stories JIT and not upfront. Else it might lead to pre-mature analysis and slicing. Some thin-slicing can be done before hand, but in lot of cases thin slices happen during development
  • Mark Stijnman

    With better tracking I mean that all the stakeholders can easily see from the finished stories that basic functionality for feature A is done, for instance, but that the advanced functionality isn’t. Better planning means that the customer gets to decide that while dropping the advanced functionality of feature A may be acceptable, the advance features for B better be completed.

    Yes, it’s extra overhead, but it allows you to communicate better with the other stakeholders. Without the user stories reflecting the different levels of sophistication, this information resides only in your head. Depending on your project size and the number of stakeholders, that might be fine, but my personal preference would be to have that info out in the open as soon as I could.

    Besides, I’d imagine that also in your approach you too have to keep track of what features you haven’t fully completed, and what levels of sophistication you still have to add? And that you also have to eventually communicate this to your customer? Why not do it through the mechanism you already have in place and that you’re both familiar with: user stories?

    No, I’m not talking about splitting to the level of technical tasks. As you say, they don’t make sense to the user. I also assumed your sophistication levels weren’t referring to technical details anyway, such as error handling or thread-safety. I’ve seen that some people regard those “details” as “things we’ll put in later”, but I don’t think you are one of them.

    And about splitting stories JIT or upfront, that depends. Since it’s really all about reducing risk and introducing control, you should take steps as soon as you identify the risk. If that happens to be upfront, so much the better. If you only find out when you start implementing a feature, you split it on the go. And since splitting on the go is always a possibility, you don’t have to spend too much time thinking about it upfront, as long as you get all the obvious ones, you’ll be sure to correct the others as you go.

  • Mark Stijnman

    With better tracking I mean that all the stakeholders can easily see from the finished stories that basic functionality for feature A is done, for instance, but that the advanced functionality isn’t. Better planning means that the customer gets to decide that while dropping the advanced functionality of feature A may be acceptable, the advance features for B better be completed.

    Yes, it’s extra overhead, but it allows you to communicate better with the other stakeholders. Without the user stories reflecting the different levels of sophistication, this information resides only in your head. Depending on your project size and the number of stakeholders, that might be fine, but my personal preference would be to have that info out in the open as soon as I could.

    Besides, I’d imagine that also in your approach you too have to keep track of what features you haven’t fully completed, and what levels of sophistication you still have to add? And that you also have to eventually communicate this to your customer? Why not do it through the mechanism you already have in place and that you’re both familiar with: user stories?

    No, I’m not talking about splitting to the level of technical tasks. As you say, they don’t make sense to the user. I also assumed your sophistication levels weren’t referring to technical details anyway, such as error handling or thread-safety. I’ve seen that some people regard those “details” as “things we’ll put in later”, but I don’t think you are one of them.

    And about splitting stories JIT or upfront, that depends. Since it’s really all about reducing risk and introducing control, you should take steps as soon as you identify the risk. If that happens to be upfront, so much the better. If you only find out when you start implementing a feature, you split it on the go. And since splitting on the go is always a possibility, you don’t have to spend too much time thinking about it upfront, as long as you get all the obvious ones, you’ll be sure to correct the others as you go.


    Licensed under
Creative Commons License