“Alice: Would you tell me, please, which way I ought to go from here?
The Cheshire Cat: That depends a good deal on where you want to get to.
Alice: I don’t much care where.
The Cheshire Cat: Then it doesn’t much matter which way you go.
Alice: …So long as I get somewhere.
The Cheshire Cat: Oh, you’re sure to do that, if only you walk long enough.”
― Lewis Carroll, Alice in Wonderland
In a recent conversation, a marketing executive asked me why the team thought it would take 18 months to deliver software. I responded with a counter question, “What do you need in the very first Sprint to deliver some value to the customer?” The executive was somewhat surprised with my question and replied that she did not have an answer but she knew she needed ‘something’ sooner than 18 months. I politely pointed out that her ‘Alice in Wonderland’ approach to leading would guarantee that the team would deliver ‘something’ in 18 months. With some reflection, she was able to communicate a clear product purpose which allowed the team to identify Sprint goals and ultimately deliver the product in five months.
Without a clear and well-communicated product purpose, each sprint objective for Scrum teams becomes less about the external effects on the economic systems (doing the right thing) and more about measures of performance (doing things right).
If a team does not have a shared consciousness of where it is going (understanding the product’s business value) then measuring how fast the team is going (its velocity) is an exercise in futility.
Velocity is used as a planning tool for estimating how fast work can be completed and how long it will take to complete a ‘project.’ For example, if a team’s velocity is 40 and the product backlog is estimated at 400 points then you know how long will it take to deliver the product backlog. Generally, a team tries its best to ‘maintain’ the velocity during a project, which makes it a ‘useful’ metric for creating innovative graphs and charts like velocity sustainability, commitment reliability, etc. Sounds familiar?
But in my opinion, using velocity as a planning tool resurrects the old sensibilities of the waterfall era.
Velocity vs Goal
A Scrum team does not work to meet velocity but it strives to meet a Sprint goal. Velocity is an internal tool for a Scrum team to gain useful insights into team dynamics, reasons for volatility, estimation etc. Velocity is a kind of collective intuition, one-time deal, and should not be used as a measuring scale because points are abstract and they do not convert to a unit of measurement.
Emphasis on velocity reminds me of Taylorism, where the intent is to make labor efficient. Scrum clearly leans towards effectiveness (doing the right thing) over efficiency (doing things right). Once the team forecasts, we don’t work to meet the velocity but to meet the goal effectively.
Similarly creating metrics around velocity like velocity sustainability, commitment reliability is not a good idea. Velocity is a collective intuition and it is hard to visualize that as metrics. A number of factors impact velocity like vacations, new team members, nature of projects, grooming, etc. A story in a Sprint becomes valuable only after it is actually used by targeted customers. Focusing on velocity is like driving a car looking into the rearview mirror plus there may not be direct correlation between velocity and business value.
Scrum thrives on customer centricity, and it is not a linear translation of product backlog. An authentic product backlog reflects the need of customers more than the dream of product owner. Using velocity as a planning tool may require you to have a deep product backlog which is a clear waste even if you intend to deliver all of them. The deeper you go into the Product Backlog, greater the chances of moving away from customer centricity.