“Are we on track?” – answered with two lines
The question underlying most governance/stakeholder meetings is ‘are we on track?’.
If your project oversight meetings are receiving updates in the form of RAG status and velocity then you are not being given the tools to do your job – which is to help guide the project to a successful outcome.
The likely range of project end-dates can be represented by two, hopefully converging, lines – the scope and the completion rate.
Velocity is NOT good enough – it cannot answer the question, ‘Are we on track?’
Isn’t it depressing that, according to VersionOne’s ‘State of Agile’ report 2017, velocity remains the single most popular way to ‘measure success’ in an Agile project.
Surely our vibrant, curious Agile community should have evolved beyond this point.
The power of two… velocity is no longer gameable
As Goodhart’s law puts it…
“When a measure becomes a target, it ceases to be a good measure.”
Velocity frequently, albeit unintentionally, becomes a target,
It’s not surprising that, if teams use velocity to communicate their progress then stakeholders will ask questions like;
- “How come that velocity is so up and down?” or
- “When can we expect the velocity to increase from 35 to over 40, after all, the team has been doing Scrum for the last 3 months”
Under such scrutiny it is natural that the team, consciously or not, will begin to inflate their estimates, thereby ‘increasing’ velocity.
The beauty of two lines is that if a team begins to inflate it’s estimates then the scope line is increased by the same amount – and so the range of likely end-dates does not change.
Note: The debate about whether it’s actually worth estimating is for another time.
Most stakeholders picture the scope as flat’ish
Once the scope has been ‘defined’ most stakeholders quite reasonably, given their waterfall experience, assume that the scope would look something like this.
Scope increase is often for the perfectly ‘legitimate’ reason, that software development is a process of discovery and requirements evolve as we get a better understanding of how the solution is used and of the technical possibilities.
However, the scope increase could also be signalling problems, like;
- High levels of rework, aka bugs, due to failure in the system. E.g. poor quality stories, a weak ‘definition of done’ or immature engineering practices.
- Vague scope and unclear vision at the start. E.g. a lack of a story workshop
Either way, stakeholders must be made aware of scope increase – as it materially affects the outcome and risk of the project.
Telling them that scope is ‘amber’ is just not good enough!
When two becomes four – and protects the team from a death march
The misaligned expectations of stakeholders has got to be one of the most disheartening and stressful aspects of software development projects.
The moral and effectiveness of the team plummets, when they know that a target is not achievable, despite what the wishful thinking PMs and stakeholders might be saying.
Extending the two lines into the future requires a range of probable scope and throughput – and so two lines become four – which then intersect to give the likely project ‘landing zone’
This is the best way to keep expectations aligned, within reach of the team and hopefully maintain morale.
There is more in my earlier blog ‘Your project has a landing zone’
Probable and possible – two lines representing potentially deliverable scope
A variant on the two lines is when they can be used to draw stakeholders’ attention to the likely range of scope to be delivered by a specified date.