Many teams who start following good engineering practices with SCRUM to be successful face this problem of velocity going low initially. Recently I saw a team which started on practicing, unit testing, refactoring old legacy code, pair programming etc on their project. The stakeholder were exited about the idea. All’s well situation. But then, a couple of sprints later what came out was that the stakeholders stared complaining about the velocity going down and were obviously not happy about it. A small down turn initially is still acceptable, but if you say, its going to take double the effort to write unit tests to complete user stories, then its a problem. The business is obviously not going to accept that.
But why did it happen in the first place??
I think there were certain aspects responsible for it. The situation was not all that bad as it looked. The velocity was not actually halved as it appeared. The reason that the velocity of the team appeared to have been halved was because all the tasks were not tracked as part of the sprint.
Example of this is that one of the team members, very good in re-factoring to good design suddenly started doing it full time. Not really working on any business story, but just re-factoring stuff. I am not saying that this is wrong. Ideally, you should be re-factoring the code that you are touching today, along side writing tests for that area or making sure the already written tests are passing. Although, a full time re-factoring might be required sometimes to make sure that you are able to deliver features faster later. But the point is that, whatever is the situation, the stakehoders should have an idea about it. The effort that its going to take and the return on that investment.
So, ideally, if you are going for some full time re-factoring task, TRACK IT as well. Add it as a item in the sprint backlog. And add its business value in terms of story points as well.
Because, if you do not do that, then you will never be able to explain your velocity trend.
Hope you all agree to that.