Stabilizing Your Velocity
When beginning with Scrum the velocity of your team starts out erratic. How do you get a grip on your velocity as soon as possible?
Starting with Scrum is challenging. Rarely the whole company is on board with switching over. There will always be people happy to see the transition fail. Maybe not even because they dislike Scrum. Change is always accompanied by resistance.
In the beginning your velocity will be all over the place. This may cause people to lose faith. They will start saying Scrum will never work. Tackle these naysayers before it becomes a problem.
Start With Managing Expectations
The expectation is that the first three to five sprints your velocity will be very variable. Your velocity will always have some degree of variability, this is perfectly normal. Make everybody aware of this before you start the first sprint. Give your team permission to suck. Failure is okay, as long as we learn each sprint from our mistakes.
Help The Team Reflect
Every retrospective is a chance to learn. Your team needs to use the opportunity to grow and improve. They need to be able to understand the situation they are in. Why do they think the velocity is not yet stable? Some questions to help guide the conversation during a retrospective:
Are some of the issues too big to finish in one sprint?
Was there a lot of rework on issues? If so, why?
Were issues clear from a functional perspective?
Was work clear from a technical perspective? Did we spend a lot of time figuring out how to do it?
Were there a lot of outside disturbances?
Did we break-down the epics into issues the right way?
Is the team focused on being busy, or on having work be idle as little as possible?
Did the team actually make a plan on how to deliver the Sprint Goal?
Did we start working on the biggest and riskiest issues at the beginning of the sprint?
Is the team working together to finish things? Do they point fingers that the issue is in test or code review so it is no longer their problem?
Focus On What Is Important
Imagine you would want to learn how to play golf. In the beginning you will do everything wrong. You will pick the wrong club. Your posture will be off. Your swing looks ridiculous. You have no idea how much force to apply to hit a certain distance. You cannot fix all these things at once. You would become paralyzed by focusing on so many things simultaneously. A better strategy would be to isolate some of the things you want to work on. Master the individual parts. Practice them together later.
You should follow the same strategy when you do Scrum. Figure out the one or two most important things to fix and address these. Do not try to resolve all issues at the same time. You will end up fixing nothing. Allow yourself to suck at some things while you are busy becoming awesome at other things.
Use Data
Like I have written before in: Bring Data To Your Retrospective, start with the facts. People may be unaware and give incorrect answers to questions. You can answer a lot of questions by simply looking at the data.
Are some issues too big? The cycle time of these issues should be high.
Was there a lot of rework? Check the reopened count of issues.
Were there a lot of outside disturbances? The sprint history contains many scope changes.
Did they start working on the biggest and riskiest issues? Look at when each issue was moved to ‘In Progress’.
Was the team focused on idle work or idle workers? Analyse the control chart and see how much time the issue spent waiting in each status.
Reflect On Your Retrospective Actions
Every sprint write down the biggest problems and how you intend to solve them. Every measure is an experiment where you check the effectiveness afterwards. Start your retrospective with a reflection on the measures taken and their success. Do this as much as possible based on data. If the measure did not achieve the desired result, was our conclusion incorrect or the measure we took to resolve it ineffective? If you keep trying to implement the same measures, then do not be surprised to get the same results.
Conclusion
Getting a stable velocity is not an easy feat. It takes time. It can depend on a lot of different factors. You need to figure out what matters for your team. Each team will have their own struggle. Figure out what needs improvement and take appropriate measures. In the beginning a lot will go wrong. Better to fix one or two things structurally, than to focus on fixing five things at once. Give your team permission to suck and the obligation to learn. This is necessary to become great!