Demystifying Agile Prioritisation and Predictability in Agile Projects

Matthew Caine Uncategorized 0 Comments

Regardless of what Agilists say, it is possible to have greater predictability for Agile Release Trains and Agile Projects than just sucking your thumb and guessing (or just relying on burndown charts, velocity and story-points).

You certainly don’t want to be the guy in the image above!

It is Easy to get in a Mess

In the summer of 2015, I was running a workshop with a group of senior managers at a large insurance company in Zurich, Switzerland.

Before we had even started to work through the agenda, the senior architect of a project bullied his way in and took over.

The group understood his pressure to discuss his project, so they gave the architect the space and attention to raise his issues. He proceeded to blame Agile for the problems in the project. There were only three weeks left of a nine month project and there was no way the project would hit its target.

In order to remove the tension that was now apparent in the room, rather than defend Agile, I found it necessary to explore the history of the project together with the group.

So we started from where he was, drew up the Sprint plans and worked backwards in time. As we went through each of the sprints I was simply asking him:

“Did the stories get done?”
“What happened to the ones that were not implemented?”
“Who said they had not been implemented?”

So…basically the usual sort of a Agile Assessment questions.

What became apparent was that stories deemed incomplete were simply rolled forward to the next sprint which made the team even more unfocused and obviously under pressure and so even more stories were rolled forward to the next sprint and so on.

It doesn’t take a genius to see that they had simply been pushing the work from one Sprint to the next, without considering the big picture and knock-on effect. The lesson learned was clearly that they were not following prioritisation rules, let alone running retrospectives to learn from their mistakes. In fact they did not retrospect at all, but that is for another time and another discussion.

Big Agile Programmes Need Planning & Predictability

We can take another example, again from a large insurance company in Zurich, Switzerland.

This was a major undertaking, to replace an old system that had been in operation since the beginning of the year 2000. It was multi-geographical and multi-business line, with two sponsors and > 20 stakeholders.

How on earth though, do they start to plan that, given that they were to just use Scrum? Well, they did not know but were willing to try as Scrum prescribes: The most valuable, shortest jobs first and adjust with each sprint, whilst measuring and reflecting on the team’s velocity.

They were concerned, clearly, but they did not know any alternative. They had not discovered their “unknown-unknowns”.

How Rich Does the Functionality Need to Be?

Then the final example involves two teams building a new Internet banking platform which was part of a core banking application, developed using the Scaled Agile Framework (SAFe). The team had to build this new application, to replace an outdated although simple enough, solution.

The challenge was understanding the depth and richness of the functionality in order to prevent gold-plating and developing functionality that analytics indicated less than 0.3% of the existing user base actually used. Ie. let’s not waste time on those 0.3% used features.

As the two teams were simply using Scrum they were in danger of using continuous development principles without getting a feeling for the entire solution.

They could have spent months developing payments and the many 0.3% payment options without making any progress on the most-used stock-exchange features.

Agile Does not Contradict Planning

Clearly these three examples represent situations where the environment in which they were being developed did not allow for continuous integration into productive live environment.

So similar to SAFe’s release train and a DSDM increment, these three “projects” needed to have some sort of plan, ability to predict and thus demonstrate control to senior executives.

In itself, a contradiction for many Agilists, but sadly a reality of our real-life World.

But how?

What Benefits does the Project Deliver?

To start with it is necessary to actually highlight the benefits that will be delivered in which month. Many teams do not do this. Instead they tend to focus on Epics or Features or worse, Stories. For stakeholders, talking about these is simply not interesting. You need to talk about the delivery of benefits.

Benefits are basically delivered by features which are broken down into stories (anyone heard of the “FAB Matrix”?).

The risk that many teams then make is to consider the whole set of stories as Must-haves and try their best to get through them, as was the case in our first example. But this in turn requires constant replanning of the stakeholders for demonstrations, reviews and planning sessions. The overhead rises, as does mistrust.

As such, stakeholders will quickly become concerned.

What’s needed is focus on benefits and in turn the features. So for example, in the month of June, project A will deliver solutions to deliver the benefits X, Y and Z. Thus, everybody knows that this is when the stakeholders that have a vested interest in X, Y and Z need to make themselves available.

What is a Must?

The question is then how to prioritise the stories within the month of June? This is where MoSCoW prioritisation comes in. By focusing on the Musts within the month of June we reduce potential gold-plating and keep focus.

  • Must can be defined like this: If it is not delivered, the entire project can be stopped.
  • Should is defined as something that is highly desirable, so we can live without it, but there is an expensive work-around.
  • Could is something that we are expecting, but the work around is inexpensive.
  • Won’t is something we will not build (yet).

It is of course our intention to deliver the Shoulds and if we can the Coulds but at least at the end of June we know that we have delivered fit-for-purpose solutions to deliver benefits X, Y and Z.

But how do we actually know what is a Must, Should or Could and how do we split something up to give us the flexibility? This is where the Weighted Shortest Job First (WSJF) technique and the Kano model help us.

WSJF helps us to identify, discuss and agree on the priorities of work and which pieces of work need to be split into smaller pieces but above all it, it helps to spread understanding of the project.

The Kano model helps us to discuss with stakeholders what is important, what is basic functionality and which things get users excited. Because at the end of a release or increment, when the solution is demonstrated, people have to see a few exciters – which may or may not be Musts, but it is good to know them and easy to discuss.

It is the power of combining the Kano model, WSJF and MoSCoW principles that really add the ability to formulate, understand and execute the plan whilst always adapting the plan as we learn and therefore demonstrate that we have the project under control.

Demonstrating Control

In the end it is about demonstrating that the Release Train or Agile “Project” is under control and by combining

  • WSJF
  • KANU
  • MoSCoW
  • Whilst never forgetting Story Points & Velocity

We give ourselves the best chance for success.

There is ultimately no reason for Agile projects to be full of mystery when it comes to planning predictability and control. We just need to be aware of the tools we can use to help us.

Are you interested in knowing more? Then contact us for a discussion.

What Next?

Want to Watch Our Online Training Videos?

We have over 1hr of video on this subject.

Want to Check Your Understanding?

Test your knowledge with our fun quiz

Need our Help?

Our half day workshops can help you solve your issues with this topic

Leave a Reply

Your email address will not be published. Required fields are marked *


*