Overview
Velocity is not for you, Bild, Spruch

Velocity is not for you

5 Comments

A while ago someone told me they let their product owners participate in estimations. And I don’t mean watch how the team estimates but really estimating stories. I’ve heard about non-programming scrum master, projectmanagers, salespeople and architects who decided their input is fundamental for getting estimations correct, but product owners were new to me. And I personally think that neither of them should ever estimate anything.

I am not so much about strictly following what is written or how people say things should be done. Insights change, the world changes and people change. If stuff works for you I rather want to learn from that instead of telling you that some guide says that it should be done different. This is not about rules. The problem I have with this is the greedy mechanisms behind this.

Would you tell a carpenter that his or her estimation for creating a table should be divided by two? Or tell the physiotherapist that your pain could be relieved in a third of the time he or she thinks? Or ask one of them to take the the average of both your estimations?

Would you really be surprised they tell you to do the work yourself if you think you can do it so fast? (And that would be the most polite response you’ll get I guess.)

One reason why people outside the team want to influence estimations is because they think they will gain from this. They feel that if they fill up a sprint with twice the realistic amount of work it will result in more profit. I personally think that it will result in more but crappy software and unhappy people.

Another reason is that some people must feel that they are in control. They are our leaders. Without them controlling every single thing only failure is certain. Trusting people to do their best is a nice thing to do when they have some free time. They are the kind of person who would tell the carpenter they could do it much faster. That is if they knew how to hold a hammer.

In the end it is very simple. It fits on a sticky if you want:

 

Kommentare

  • Fabian Lange

    Niels,
    I think you have a great point here, but applied the wrong label. Velocity is in fact a tool for externals to plan and estimate when a team will have done something. However you are right, that the inner workings of story points and velocity can only be influenced by the team itself. Otherwise velocity would loose the property of being a good planning tool

    Fabian

  • Niels Talens

    8. October 2012 von Niels Talens

    Hello Fabian,

    Just to be clear:
    To which externals are you refering and why do they need to plan when a story?/sprint? is going to be done?

    Niels

  • Andreas Ebbert-Karroum

    Hi,

    it is essential to be precise here. The terms “team” and “not for you” are a bit vague. There are two teams in Scrum, the Scrum Team and the Development team. The latter is one of the three roles that make up the Scrum Team.

    Since the Product Owner is part of the Scrum Team, the Velocity is also for him, in order to be able to extrapolate the velocity into the Product Backlog for release planning purposes.

    In the other hand, the estimates should be done by the Development Team only.

  • Niels Talens

    10. October 2012 von Niels Talens

    Hi Fabian & Andreas,

    I do not really agree with “Velocity is in fact a tool for externals to plan and estimate when a team will have done something.”. (And now I mean the Scrum/project team.)

    That is not the purpose of velocity and should never be seen as that by people outside the (Scrum) team. How are they going to estimate when a story is ready? By mapping point to hours possibly? That’ll be terrible. Especially if they do not really understand what it is and use it as a mini contract or commitment. Velocity is not something they can or should use in any way.

    If they want to know what will be delivered this sprint the sprint backlog is the best representation of that. Not the velocity.

    For the releaseplanning: the points given to product backlog items are not as specific as the ones in the sprint backlog. Stories tend to be much bigger in the product backlog

    Therefore velocity which comes out of specified and defined strories/tasks from past sprints does not apply to product backlog stories.

  • Marc Clemens

    18. October 2012 von Marc Clemens

    Hi Niels,

    first, it seams that you mean something different with “velocity” than Fabian, Andreas and me, too. In my understanding, velocity is measured in the estimation unit (and size) on Product Backlog level. If user stories with story points are used, the velicity unit is Story Points per Sprint. The primary reason is the planing for time schedules greater than the current sprint. And to do this is part of the PO job, so he need the velocity.

    Second I want to come back to your blog article. Sometimes I (in the role of a PO) have the feeling that the team misunderstand some of my Product Backlog Items completely during the estimation. So I already thought about participating the estimation actively, giving my expected estimation, comparing it with the team value. So we (as Scrum Team) see where are misunderstandings and talk about them. The result is a better common understanding of the scope or my better understanding of the complexity. Both helps me to write better and smaller product backlog items. Therefor POs estimations are not so bad.

Comment

Your email address will not be published. Required fields are marked *