Managers often ask me – “What should I do to increase our team velocity?” And the answer I give is very simple – “Just double the story points for each user story”. After that they usually smile and think I am joking. But I am serious, as usual.
Managers not only expect team to increase it’s velocity in this sprint, they expect team to continuously improve velocity. “Give me 10 story points increase each sprint!”. I also heard managers complaining that team has the same velocity for the last 7-10 sprints. We have this great metric – team velocity – for planning and budgeting. Going from sprint to sprint we collect the statistics and understand what amount of work team can do during the next sprints. But management is often too optimistic about this metric – they start measuring everything on base of velocity, even the team productivity.
Velocity is a great tool for predictions, don’t ruin it using as the team productivity measurement. You can tell a lot about the process looking at the velocity diagram, but that will not provide you the whole picture – as usual, the world is more complicated than we assume it to be.
The key to the success is not increasing the velocity continuously, the key is to keep the velocity stable and predictable. And a good team keep the slight increate trend keeping the stability and predictability.
Remember, each tremendous rise in today’s velocity is probably the tremendous fall in the future. Of course, sometimes things appear to be easier than we expected or the risks do not happen. But, to be honest with you, when you had this for the last time? Never? You know, if something can go wrong it will go wrong.
Productivity and velocity
Let me tell you the real story. One of our clients was not satisfied with velocity – the team was making smh about 27 SP per sprint. Client believed we can make at least 35 SP. Why? Because he planned the deadline date according to belief that our velocity will be 40 SP and now we need to catch up… (Don’t ask me where PO took this number, he just “believed in the team”). Project manager promised to manage this. (Don’t ask me what PM is doing in the Scrum team, but it is the reality of outsourcing companies). So he did – he set the target for the team to increase velocity. The problem with the development teams is that…they are smart. They are too smart. So what they did? They just started giving the higher estimations for each user story! Thinking whether it is 2 or 5? Of course 5!
It was a kind of story point “inflation” when 1SP started including less work effort.
Fig. 1. – What team thinks about your performance measurement metrics
The other team I worked with was even smarter when the management pushed them to increase the velocity – they just added “0” in the end of each estimation, so 1SP turned in 10 SP. Wow! They suddenly started making 250 instead of 25!
Velocity chart diagnostics
If you are a Scrum Master you can make this trick that I love so much. Just enter the team room and go to the project board. Look at the velocity chart and tell the team their fortune…
If the chart looks like this:
- Team is pushed to work faster (by the internal or external forces). But every time they face some technological challenges or uncover the new requirements.
- Looks like the team can’t finish some of the stories during 1 sprint, but finish them in the next one. That is why there is the difference between the sprint’s velocity. There can be several reasons: the issue with the requirements – user story is not ready for the development or user stories are too big – they can’t be completed in a sprint.
This diagram is very optimistic:
It seems that we “overestimated” the complexity, wow! In reality I would worry a lot about if I see this diagram in my team. We are moving too fast – that can’t be true. We miss something or cut the corners. So we’ll get what we deserve in the nearest sprints and we’ll see smth like that:
Architecture becomes complex, we are ignoring the tech debt (paying it off usually helps us to keep the speed, but not to increase tremendously, as it requires some time too). That is ok and pretty understandable. But the management wants predictability and this scenario can’t be predictable enough (except from the prognosis that we’ll be slowed down soon).
Real velocity diagram from my projects (so you won’t think I am too smart – I just made all these mistakes before)):
Fig. 2. – Towards the epic fail
It was harder and harder to implement any changes. Team got the legacy code from the previous development team. We were rather optimistic in the beginning, but all the new changes appeared to be a disaster.
Ideal case (never seen the really ideal one):
In the beginning there are usually some fluctuations – while the team sets up the environment, communication flows, etc. Then the velocity stabilizes- now you can see the team’s real flow. Complexity of the product has risen, but the team works on it step by step, not cutting corners and paying off the tech debt.
So, remember:
@tisquirrel 
Reblogged this on Duong Tiet's blog.
Velocity is a metrics that can easily be misunderstood by traditional managers. It is for forecasting. Increasing velocity is like saying “can you please increase tomorrows temperature?”.
Exactly 🙂
Thanks Galina for posting this nice article. It’s all a well-known fact to product managers and developer, but maybe not for other people.
I hope you don’t mind if I link your article from my blog.
Of course I don’t mind) This is not clear for some project managers and top managers. Developers understand it clearly. As for the Product managers -I was working almost all the time in software development outsoursing companies – we rarely had product managers on board.
I love this article. We’re currently nearing the end of our first year of our agile (Scrum) transformation. As I’m educating folks in the business about the process velocity is something that I try to spend a lot of time on. The message I’m trying to send is that only the team should ever care what their velocity is. Other people can use that velocity to do some planning, but shouldn’t think it’s a number that they can ask for changes to. In my mind the conversation goes something like this:
Manager: “Hey, we’ve got a really important deadline coming up in a few months. I’d like to see the team’s velocity increasing.”
Me: “Why would you want to see that?”
Manager: “So that we can hit the aggressive date we’ve set.”
Me; “Ahhh, I understand. You had me confused. You don’t want the velocity to increase, you want the team’s capacity to do work increase. Sure, that makes great sense. Fortunately, you know the things you need to do to increase capacity. I actually haven’t seen you do any of those things. What are you willing to commit to to help the team get more work done?”
*actual potentially valuable discussion goes here*
Thank you very much for sharing this!
Thank you for your feedback. Great example you mentioned! That is a brilliant reply to ” I’d like to see the team’s velocity increasing.”! 🙂