Revolutions Over Velocity
You probably have ridden a bike a couple of times. And you probably have used one with a couple of gears. So I think you are in a good position to reflect on the notion of velocity as still promoted by quite a few Scrum fanboys.
Hereâs what I mean:
Imagine youâre riding your bike on a horizontal road. Youâre cruising at maybe 20 km/h and are using the 4th gear. What do you do if you want to increase your velocity? You pedal faster. You manage to go at 25 km/h while still using the 4th gear.
As youâll soon notice, though, riding the bike has now become more strenuous. Pedalling faster means more revolutions of both gears, the one attached to your pedals and the one connected to your rear wheel. And more revolutions means more energy put into the system.
Since you donât like to exhaust yourself and you have more than one gear to choose from, you switch to a higher one, e.g. the 5th or 6th gear (on your rear wheel). And what happens is that you are able to keep your velocity while lowering your pedalling frequency back to the former level. Less revolutions, less energy needed for the same speed. Great!
Multiple gears on your bike let you vary your velocity while keeping your energy investment roughly the same.
This becomes more obvious in a hilly terrain.
Imagine the road rises, first gently, then quite steeply. What do you do? Do you try to keep your velocity? No, I donât think so. Maybe at first - until you realize that it becomes harder and harder, that you have to put in more and more energy.
Sooner or later, however, youâll give up on velocity and focus on energy. Youâll shift down to a lower gear to keep the number of revolutions constant which will lead to a decrease in velocity up the hill.
Keeping the velocity constant is not sustainable in a hilly terrain. And the longer your ride is the less so.
When I got into mountainbiking I learned that I have my personal ideal pedalling frequency, and my girlfriend has a different one. When we go up the mountains we both are trying to keep our individual frequencies constant instead of our velocity. And the one time on my first mountainbike tour I did not stick to that principle I really, really had to pay for it😱
Let me summarize this experience with a principle:
Principle of constant energy expenditure (PCEE): Keep the number of revolutions per unit of time constant in varying terrain, not the velocity.
And the more gears you have on your vehicle the easier it is to follow the principle (and also have a higher velocity than with less gears).
I think, this also applies to software development.
The Terrain of Software Development
Requirements you face in software development are varying in their difficulty. Some requirements take more time to implement, some less. The percentage of time you spend on research (requirements, technologies, legacy code), design (architecture, algorithms), and coding varies with each requirement, as does the absolute amount of time spent in each of these phases.
I think this can be compared to the varying steepness of a road. Letâs say youâre developing on a horizontal terrain if you can produce the solution to a requirement in 2 days with all the necessary analysis, design, and coding.
However, if it takes you 3 days or 4 days or 10 days to produce the solution, the steepness of the software development terrain has increased.
These are just arbitrary numbers. Their absolute values are not important. Iâm just after their relation; more effort means steeper terrain:
Steepness: 3 days / 1 requirement > 2 days / 1 requirement
Itâs the same as 30 vertical meters per 1 km distance > 20 m per 1 km distance, 3% incline > 2%.
In general that means steepness in software development is measured in time needed per requirement. More time equals more difficulty.
The Velocity of Software Development
Velocity turns this relationship upside down: the more requirements per time the higher the velocity:
Velocity: 1 requirement / 2 days > 1 requirement / 3 days
The same on your bike: the larger the distance per time, the faster you go; be that the vertical or the horizontal distance.
Interestingly, though, when you are trying to be agile by doing Scrum with Story Point (SP) estimations youâre not using the number of requirements as the numerator in the velocity formula.
A requirement is what counts for the user. Thatâs a legitimate analog for distance in biking. Because distance is what you want to cover when biking.
But SPs are an analog of time - even though youâre not supposed to convert them to time. Estimating requirement A with 5 SPs, B with 8, and C with 3 means, you think A will take more time to implement than C, but less than B. (Even if the term âtimeâ is not used but âeffortâ, SPs are about time.)
Story Points per sprint duration, e.g. 40 SPs / 2 weeks, thus essentially means dividing time by time. That does not make much sense to me. And it does not fit the purpose of calculating a velocity, I think.
Revolutions of Software Development
Customers donât much care about how difficult it is to produce a solution for a requirement (unless you attach a price tag to it). What counts is the number of fully implemented requirements per unit of time or how much value is generated by them (which unfortunately is difficult to calculate):
3 requirements / 1 week > 2 requirements / 1 week
3000⏠value / 1 week > 2000⏠value / 1 week
Yes, the customer is interested in the velocity of a software team, but a real velocity with a tangible and relevant numerator. A teams âagile velocityâ is of no use to a customer. She would not even understand, and she does not care. Story Points are not valuable in any way to her.
Focusing on Story Points thus to me is⊠waste. Who should be impressed by keeping the number of SPs the same per iteration? Itâs meaningless to calculate SPs/iteration length and also striving for keeping that constant (or even increase it). Itâs not a measure of velocity!
If anything at all, Story Points help to gauge the steepness of the requirements terrain. Because if this week requirements A,B,C are estimated with 5,8,3 and next week D,E,F are estimated with 8,5,13, then the steepness has risen, because this week the requirements are deemed easier (16 SPs) than next weekâs (26 SPs).
Now back to biking and the PCEE: If sustainable biking means keeping the number of revolutions pretty constant in varying terrain, how can that be mapped to software development? We sure want to conserve our energy there, too, I think. We are not in the sprinting business - despite what Scrumâs trying to tell us â, but in the ultra marathon business. We donât need to be very fast once in a while over a short, horizontal distance, but be able to run constantly for an unknown time in a terrain of very varying steepness.
In biking energy is tied to the number of revolutions. Weâre trying to keep this number pretty much the same while riding a terrain of varying steepness by switching gears.
Now, what is energy, whatâs a revolution in software development, how to switch gears?
Iteration frequency
A revolution is a cycle, an iteration. In software development thatâs transforming requirements into something tangible for a stakeholder in order to get feedback.
Keeping the number of revolutions the same thus means the number of iterations per time unit has to be pretty constant, e.g. 5 iterations / 1 week or 12 iterations / 2 weeks.
Both examples are formally valid, but I think the numerator should be > 1. The simple reason: Iterations can only be measures in full. There is no such thing as an 80% iteration. So if you want to measure the number of full revolutions, your âpedaling frequencyâ, go for something:
Frequency: 3 iterations / 1 week > 2 iterations / 1 week
The question in software development is: How many times did you get feedback per unit of time. In general itâs better if the number is higher, Iâd say. But according to the PCEE itâs even more important to keep the number constant even if the terrain gets tough.
Scrum meant well when it suggested to work in a cadence, to constantly iterate in short cycles (shorter cycles, at least, than were used before). But I think, it got it wrong. The point is not to keep the iteration length the same. With Scrum the numerator is always 1, e.g. 1 iteration / 2 weeks or 1 iteration / 1 week.
However that's not a good idea which for example is proven by many discussions about whether a Sprint was successful if not all stories got finished in the constant allotted time. It's a moot point, in my view. It means clinging to a notion of velocity, i.e. distance per time.
Iterating is not about whether a single iteration is a success or not. Iterations are always a success, they are experiments - even though they might lead to unwanted/unexpected feedback. Iterations are information gathering devices. They cannot fail even if you don't like what you find.
Rather iterating should be about the number iterations per time unit. This number should be pretty constant. It might go down once you start climbing a hill of more difficult requirements, or it might go up if the requirements terrain is getting easier. Thatâs important to notice, because itâs a signal to switch gears to get the iterations âback to normalâ. You always want the information gathering rate to be the same.
The velocity, on the other hand, i.e. the distance per time covered by a revolution, can and should vary! Thatâs the essence of the PCEE. That means itâs preposterous if Scrum is pushing teams towards constant velocity. Iâd even say, the very notion of constant velocity is counter-intuitive and counter-productive.
If keeping the number of revolutions constant on a certain level matching your stamina is what enables sustainable levels of operation (not only in biking), then the distance covered per revolution or unit of time is not important.
Distance with Steepness
Whatâs distance in software development? It is the number of requirements or an overall scope. But this distance always comes with a steepness. Requirements are of different difficulty. Sometimes a requirement of a certain value is easy to implement, sometimes itâs very hard to achieve the same value.
That means, with a given number of revolutions per unit of time you cannot expect to always cover the same distance.
The important thing is: Keep pedalling with the same frequency, keep iterating at the same frequency regardless how difficult the requirements are.
Huge or very difficult requirements get converted into code with the same frequency of iterations as small or easy requirements, e.g. 5 iterations / 1 week.
Gears
But what to do if the frequency drops? Switch gears! If you find yourself down to 3 iterations / 1 week, then change something to get back to 5. What to change? Your requirements slicing process.
Keeping the number of revolutions up is a matter how you approach requirements analysis. If it becomes harder to convert requirements into tangible increments for feedback, you need to look closer. Slice them more thinly. Or refuse to enter the production code producing process (which is the one to keep at a constant iteration frequency); instead spend more time in fundamental analysis or some other research, maybe build a prototype instead.
Switching gears means to vary the size of the chunks you bite off of requirements. Smaller bites can be translated into feedback ready increments faster than larger bites.
How large your bites can be depends on a number of factors, some personal, some project or technology specific.
Also, switching gears can mean to refactor code. Thatâs like adding another gear to your selection. Afterwards you can pedal faster.
Summary
The PCEE is saying: Keep your iteration frequency constant! Thatâs more important than striving for some velocity. The reason: Looking at velocity is bound to frustrate and/or exhaust you. Sustainability is a matter of dealing economically with your energy.
The energy you have, manifests itself as attention. Hence: Spend your attention wisely. Spend it on a constant number of iterations per unit of time. That way you donât exhaust yourself by chasing ever evasive velocity goals. It's the number of iterations, not the size of their scope.
Deadlines are exhausting. Donât go for them. Really, donât! Youâre not on a Tour de France, youâre not a top notch athlete. (And even a professional racing cyclist is pretty much trying to keep a constant number of revolutions - just with a higher frequency in a higher gear than you.)
Youâre riding your software development bike on an unknown terrain. You donât know what kind of hills (or valleys) are ahead of you. Donât exhaust yourself in a chase. Donât choose velocity as your metric. Choose revolutions per time instead. And then find your rhythm.
PS: Here's another analogy which just came to my mind: Think of a stock buying plan. If there is a stock (or ETF) you have great confidence in, then set up a plan to constantly invest. But don't buy a fixed number (e.g. every month 3 shares)! Rather buy for a fixed price (e.g. every month for 250âŹ).
If the share price goes up, you'll buy fewer shares, if it goes down, you'll buy more shares. In any case, though, you stay invested in what you believe in, regardless of how the market develops. By sticking to a fixed amount of money per time unit you invest a constant amount of energy while the market varies. If it goes up the number of shares you buy drops (less distance you cover with your energy), if it goes down the number of shares rises (more distance you cover).
Your "velocity" (number of shares bough per time) varies, but you keep making progress according to the constant "energy" you can invest without risking too much. You are making varying progress depending on the ups and downs of the stock market terrain. But you're progressing nevertheless so that when there is an opportunity you can sell a constantly grown number of shares for a high price.