Scrum Puzzle #3
Well looks like everyone got that changing the sprint length is a bad idea. Here are the key learning points for me in Scrum Puzzle #2:
1. Velocity is not linear, all it tells you is how many points a team usually complete in a fix period. As soon as you change that period you no longer have data to make any prediction. You cannot assume that if a team do 30 points in 2 weeks, that they can do 15 points in 1 week. The team may for example do all the coding in the first week and all the testing in the second. So after one week they would deliver 0 because nothing is tested. I’m not saying this is how all teams work, or even how teams should work, all I’m saying is that knowing only the velocity for a 2 week sprint you cannot know anything about where the team will be after 1 week.
2. Velocity is not a commitment or a target. This is a common misconception. Just because the team delivered 30 points last sprint, doesn’t mean they will again. Velocity can be used to make a guess about what can be delivered but it does not make it happen. I commonly see Product Owners falling into old project management habits of making commitments based on guesses, and then making it the team’s responsibility when it is not delivered. If you start doing this, a range of undesirable effects start to happen. Please start to game velocity, teams unconsciously drop quality to meet the commitment, and business get used to having the sometime unreasonable demands met. It might seem okay to do this once, but it never only happens once. It takes courage to break the cycle, and to trust that the team will deliver the best thing they can, and to work with that.
Okay onto Scrum Puzzle #3:
You work in an organisation doing Scrum across multiple teams. You are one of the ScrumMasters. The development manager asks if you can work with the other ScrumMasters to have all the teams setup their boards in the same way, using the same colours to mean the same things, e.g. pink for bugs. He thinks it will help other people in the company understand the boards and therefore help with buy in to the Scrum process across the company. What do you do?