Why there’s value in a glass half empty

When teams, and certainly Scrum Masters, begin to learn scrum there is an adherence not just to the framework but to the little bits of support aided to it in order to prop up the more abstract bits. The double edged sword that is the Scrum guide is a lightweight simple explanation of how to implement the system. This makes it easy to implement but leaves a lot of gaps for the individual teams to sort out themselves. When this is done without Agile coaching of some kind it can often lead to Zombie Scrum; where teams conduct events and illustrate transparency but quickly fall back into bad habits such as a high amount of work in progress. One of the weaknesses and strengths of the Scrum Guide is that it tells teams what to do, but not how to do it. But to defend the document, it does put in safeguards.

And the main guardian in this respect is the Sprint Goal.

Another of the deliberately vague parts of the Scrum Guide is the mention of estimates. Again it adheres to the principle that teams should work out how they want to adopt this themselves and this is a good principle. But lack of experience and lack of coaching will tend to dictate that they will utilise well known (or the most popular Google search) methods such as Pointing. For those who do not know what is involved in the process of Pointing, it is a way of assigning abstract integer values to small coherent pieces of work, based on how much you know about the effort to complete the piece of work. When a sprint is finished then the points for the work completed is added together to give what is called a ‘velocity’. Over a number of sprints this can be averaged to give an indication of what a team’s sustainable workload is.

Which is a good thing.

Until it causes a shadow that Zombie scrum can hide in.

Velocity is an indication of how much work ‘can’ be done in a sprint. It is not an indication of the amount of work that ‘should’ be done in a sprint. During Sprint planning there is a temptation for a team to take in the number of product items that add up to the rough velocity. But it’s an indicator not a finish line. The real finish line is the Sprint Goal, the targeted increment of the product that can be built. Team members may shrug and not see the harm with ‘filling up’ the Sprint. And when the teams have less ‘Agile maturity’ this tends to be the case with Sprint goals that lack coherence and are just a list of product items. But as maturity increases the team should wean themselves off this idea and become more disciplined regarding the increment they are building. Otherwise there is a good chance that bad habits will start to appear. Teams and perhaps even the Product owner becming confused regarding the priority of the items. Developers spreading ‘across’ the board causing a high level of work in progress and increasing the chances of not completing high priority items. The more this happens, the more chance there is of causing knowledge ‘Silos’ as learning methods such as pair programming become sparsely used. Product items become victims of Zombie scrum, blocking up the mock Kanban flow and taking multiple sprints to get down river.

All of which can be mitigated in a very simple way.

Jeff Sutherland and Ken Schwaber are more than conscious of potential bad implementations of Scrum. During Sprint Planning, the 2020 revision of the Scrum Guide asks that Product Owners bring the Sprint Goal to the team, and it is then the team that chooses the items from the Product backlog. This change tries to stave off the temptation just to fill up the Sprint so that the team is ‘always busy’ and retains the coherence of the increment built. This does not mean that more work cannot be brought into sprint once the goal has been completed. It just prevents the new work from getting in the way of the goal.

A glass half full is actually a full glass if you can only really drink half of it.

Filling it up to the top just means you might not be drinking the half that you need to.