In the business opener for the Q1 PI Planning event, I thought predictability was a key indicator for us to collectively focus on across Q1 and beyond. I spent a lot of time reflecting on what the Enable Q4 plan looked like vs the reality that transpired throughout the quarter.
In essence, I know software delivery is in a complex space. And in complex work, everything takes longer than predicted. Our estimates are filled with more uncertainty than certainty. And humans by nature are optimistic. The model below, Hofstadter’s Law, illustrates that actual time even exceeds those estimates that take into account Hofstadter’s Law in most cases!
We know in complex knowledge-based work, unknowns aren’t known upfront and the traditional approach of determining how long each part of the process will take, i.e. breaking down an epic into features, sizing them and adding a buffer on top is clouded with uncertainty.
The variance I see in data such as cycle time and velocity, and my observation from Q4 backs this up.
But this isn’t very helpful for our stakeholders.
Stakeholders are also operating in an uncertain, VUCA world. They need reassurance that what we have set out to deliver is on track. They need to be able to plan their activities around our delivery and replan if something changes.
So, how do we become more predictable with our customers (stakeholders)?
I believe that leaning into scrum as a framework can help.
Scrum by its very nature enables predictability. Imagine we have a roadmap, and various core milestones we are working towards:
In scrum, we aim to deliver value rapidly to our customers. The way to do this is through iterative development. We want to slice up our work into sprints in order to achieve a goal. We want to do the minimal amount possible that releases a valuable increment to our customers. What I mean here is we want to release early and often, not as a big-bang large release at the end of a project.
Incremental delivery enables the various inspection points throughout the scrum framework and allows us to inspect (reflect and learn) and adapt if/when it is applicable to do so.
For context, this diagram is taken from the Evidence-Based Management framework – Home . If you think that the green small circles are our sprints and the intermediate goals are our milestones that would have been highlighted in the roadmap above – the strategic goal would be our product goal (or when the overarching initiative’s value will ultimately be released).
Action #1 – can we become more predictable by ‘right-sizing’ our product backlog items?
Batch size is really important. Breaking work down into smaller chunks improves efficiency, visibility, cycle time and quality. It also allows for faster feedback loops which in turn leads to better outcomes.
Product Backlog items that can be ‘Done’ by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
(the Scrum Guide)
Our sprints are 10 days. That means we have a service level expectation (SLE) that our cycle time should be less than 2 weeks. However, we always have more than one PBI in the sprint backlog. If as an example we had 5 PBIs in the backlog, our SLE should be much lower (in this example we could suggest perhaps 2 days CT because 5 PBIs / 10 = 2 days each).
As a team, if we could agree on a typical SLE or set it intentionally as a baseline for an experiment:
- in sprint planning, we could use it to help manage capacity as above.
- in our daily scrum, we could use issue age to highlight any outliers and replan (or split) as necessary.
- in our sprint retrospectives, we could inspect and change the SLE if applicable
The aim here is for us to create a smooth and even flow of work in our system. If we can do this then predictability and tracking become so much easier.
Action #2 – can we ensure we are splitting our stories in a way that ensures we are releasing incremental value throughout the lifecycle of an initiative and adding bells and whistles incrementally?
The way stories are written and refined can really aid flow and collaboration.
Just for clarity, this section isn’t about sticking rigidly to a plan, I fully understand that scope creep happens – sometimes we learn and need to adapt. The #1 agile value is ‘responding to change over following a plan’.
What I am aiming at in this section is the importance of being prepared well enough in sprint planning so that we can be really intentional on what we are going to be working on, why it is important and aligned as a team so that we aren’t afraid to classify something as a ‘won’t do yet’ item if we don’t have the time and the feature won’t add the necessary value. After all, we can always revisit it at a later date incrementally.
I feel these are two key steps that will help the scrum framework ‘work’ for us, allow greater transparency and improve predictability.