Qcv (Quality of non-declining velocity curve)

This curve is a sort of model about how theoretically the practices are related to the quality, and how the quality is related to the velocity.

Some practices related to the quality are very obvious, code convention, pair programming, for instance.

The quality is related to the velocity because a good code base makes the next feature cheaper.
At the other side, a bad code base means that you will go slower.

The Qcv level so it is the "quality of non declining velocity", a point such that you will keep the same velocity.

Almost the same concept has been introduced under the name of the quality/speed barrier, that can be said in this way: "there is a point where below it you need to go slower to go better, but above it you go faster because you go better." (said J.B. Rainsberger in this video 00:58)

So how do we know where we are?
Doing lesser and lesser story point at any iteration, means being under Qcv, seems to me.

The main question is what to do then?
Introducing "quick fix" is not a medicine to go faster because it means corrupting the code base, so it's even worst.

Instead, some time must be spent to re-inject the lost quality.

Can you convince the p.o. to do it? It's about how to convince the p.o. to accept tech stories.
According to Henrik Kniberg, in "Scrum and Xp from The Trenches" it should be possible:

• Team: “We have some internal tech stuff that needs to be done. We would like to budget 10% of our time for that, i.e. reduc focus factor from 75% to 65%. Is that OK?”

• Product owner: “Hell no! We don’t have time!”

• Team: “Well, look at the last sprint (all heads turn to the velocity scrawls on the whiteboard). Our estimated velocity was 80, and our actual velocity was 30, right?”

• PO: “Exactly! So we don’t have time to do internal tech stuff. We Need new features!”

• Team: “Well, the reason why our velocity turned out to be so bad was because we spent so much time trying to put together consistent releases for testing”.

• PO: “Yes, and?”

• Team: “Well, our velocity will probably continue being that bad if we don’t do something about it.”

• PO: “Yes, and?”

• Team: “So we propose that we take approximately 10% off of this sprint to set up a continuous build server and other stuff that

• will take the pain off of integration. This will probably increase our sprint velocity by at least 20% for each subsequent sprint, forever!”

• PO: “Oh really? Why didn’t we do this last sprint then?!”

• Team: “Er... because you didn’t want us to...”

• PO: “Oh, um, well fine, sounds like a good idea to do it now then!”

p.s. I spent some time thinking about the numbers of the example. Here is my ideas about: if the team don't do tech stories, they will keep going slower: 30 story points (instead of 80), so the focus factor will be 28% (instead of 75%).

If they will do the tech story at the next sprint, so they can come back at a normal velocity of 80 story point (focus factor 75%) they need to subtract the 10% of the time of the next sprint for it (and should do it at the beginning of the sprint to capitalize as earlier as possible this value). So there is left the 90% of the time of the next sprint doing normal stories at the normal velocity, so the number of story points will be 72, instead of 80, and thus the focus factor should be 67.5% (not far from the suggested value of 65%, actually), instead of 75%.