Oct 08

Velocity is not for you

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.)

 Crappy software and unhappy people

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. You can fit it on a sticky if you want:



Permanente koppeling naar dit artikel: http://agilethings.nl/velocity-is-not-for-you/

  • I totaly agree with this. It is almost insulting to teams if you question their estimations. It is the same in asking them to increase their velocity. It’s like asking a someone to loose weight because you thing he or she is overweight even if it is not the case. It is insulting.

  • Linda van der Pal

    I have been in a team where this actually worked out. But I do have to say that the product owner only had a minor voice in the estimation. What we used it for was mainly to educate the PO. By forcing him to actively join in on the estimation he got a better feel for how much work particular issues were. Of course his estimations were useless in the first three sprints, but after that he had a pretty good grasp of how much work something would be.

    • It can work to educate a PO or any other person who is not within the team. However be careful with this. To often I have seen that it also gives the PO the idea that it is his or her team and it opens the door to other interferences towards the team. Make things clear. Velocity is for the team, and the team only.

  • Maurice le Rutte

    Making an estimate is not for a Product Owner who then drives down the estimate, but can be done by Product Owners who are knowledgeable and engaged enough to stop doing that.

    Velocity is not for the team but for the Product Owner. If anybody drives down the estimates (PO?) then velocity will automatically follow. Teams should only accept a certain amount of work in any timebox after they’ve broken them down, regardless of the original estimate assigned to the item, which becomes irrelevant at the time an item is taken into execution.