The futility of finishing all PBI’s in the Sprint
About ten years ago I was a competitive rower. Our goal that year was to qualify for the Under 23 World Champioinships that were held in Amsterdam that year. Starting around September we trained almost every day of the week, many times twice a day. We did long workouts, short workouts, slow, intensive, weights, sprints, cross training, you name it, we did it.
At intermediate intervals we measured our own performance to see whether we were on track. We did this by comparing ourselves against ourselves, against others, at training camps and at races. By doing this we could establish whether we were on the right track or whether we needed to change something in how we were doing things.
A training plan for four weeks might look a bit like this. Colours indicate different types of training. There are a couple of key moments in there as well, marked in red.
We can translate this training plan into Scrum terms. The planned four weeks become the Sprint. All the programmed workouts become PBI’s, and the key moments marked in red are Sprint Goals. The goal I mentioned at the start of this article becomes the Product Goal. More lofty, further away, and not attainable in a single Sprint.
When we look more in-depth the comparison holds up as well. All workouts have an assigned stress score, an estimate based on practical experience from working with similar crews, and theoretical knowledge of physiology and training.
In Scrum, this stress score becomes the size of the PBI. And like the size of a PBI, the true stress score of a workout as perceived by the athlete reveals itself only after completion of the workout, and is based on all kinds of real life factors such as accumulated fatigue, psychological stressors, sleep quality, or any other factors that might influence physical fitness.
The futility of finishing all the PBI’s in the Sprint is apparent.
It is the equivalent of measuring success by the number of workouts that you did, or whether you accumulated the exact amount of stress points planned.
It is the equivalent of saying “I’m not happy with this week, because I couldn’t do every training session the way it was planned”.
There are possibly very good reasons for it: too tired, very bad weather, a death in the family, or study stress are all too common reasons for not being able to perform a training program as planned.
But it doesn’t matter, because the evaluation of success lies at the key moments: the goals you set, whether they be main goals or intermediate goals.
Translated to Scrum this means evaluating performance on the Sprint Goal and on your progress towards the Product Goal, and not on whether you fulfilled the planning. Even if you don’t reach the Sprint Goal sometimes that’s fine, as long as you keep your eye on the prize and keep progressing towards that Product Goal.
Of course not being able to fulfil the plan, like most things, is worth reflecting on. The true intensity of the plan might have been underestimated, in which case you do a little less the next time (plan fewer PBI’s). It might have been the case that the impact of outside forces was higher than expected, which means you need to take these events into account in making the plan as well.
Being bummed by not finishing all the PBI’s is as futile as being bummed by not being able to do all training sessions. Success is measured by the goals you achieve and the value they deliver, not by how much work you did.
