Quite often in the agile world, you will come across pieces of work that are deadline driven.
Whilst it can be negotiated in some instances, other times it’s just something we have to deal with as this is the world we live in.
Some people (myself included) are focused on delivering value continuously, whereas others still have a deadline orientated mind-set because, it may be the only way they’re familiar with working, it may be imposed upon them (legislative/regulatory for example) or quite simply this may be the only way they motivate themselves to actually do the work.
For these scenarios we need to know how best to handle this when working on agile projects as one of our biggest challenges is how to manage the delivery when working to a deadline.
You will have stakeholders/PO’s/management pressuring you to ‘meet a deadline’ yet unwilling to compromise on scope.
“You have to deliver it all” is a typical response for those that have not had the benefit of coaching on what agile truly means, and it can create an unnecessary pressure on the team.
So how do you tackle this?
Well for one, we know that delivering “everything” directly contradicts agile principles.
Remember, Agile is about working smarter, rather than harder.
It’s not about doing more work in less time; it’s about generating more value with less work.
You will need strong customer negotiation/stakeholder management (as well as a lot of patience!) skills to get this message across, relying on management where needed to help support you.
What I find the most helpful in these scenarios is showing stakeholders that if they want ‘everything’, just how long it will take.
For those curious on how best to get this message across visually, a follow on post will show you how you to do this using data/probabilistic forecasting.
However, our question today is deadline driven.
So how can we do this visually?
Potentially Deliverable Scope (PDS) Chart
This chart uses Monte Carlo simulation and the actual movement of cards across a team's board to predict how far down the backlog a team will get for a specified budget or timeline for a selected project or release.
The model predicts the ‘Probable’ and ‘Possible’ deliverable scope, which helps the business focus on the marginal scope.
Take this example chart (generated 14th Feb) with a finish date of 3rd March for a project/release:
The chart represents the current backlog order, as well as the sizes of each backlog item being relative to the points estimate per PBI (user story).
Pink items are currently In Progress, Grey items are To Do.
The title, person assigned to (removed for the purposes of this data) and unique ID for a backlog item is also visible, with the ability to click on an item taking you to the actual backlog item in your respective tool (Jira, TFS, etc.).
There are 3 areas to look at:
1) Anything above the ‘Probable’ Line
These items will almost certainly be delivered.
As you’ll see for this team that is currently everything that is In Progress.
2) Anything below the ‘Possible’ Line
These items will almost certainly not be delivered, however if a stakeholder sees something we are definitely not going to get to, this allows them to visually see the priority of an item and if this needs to be moved up/down the backlog priority.
3) The scope that *could* still be delivered
This should be the area that everyone focuses on.
This is where the team *could* get to by the deadline if the team and business work through the priorities to improve throughput. This could be through story slicing, closer collaboration, etc.
This chart can be run every few days, with the ability to change date/data range used, scope change, throughput increase or an increase in any rework needed.
This is hugely beneficial when wanting to visualise using data (rather than speculation) how far down the backlog you will get by a given date, which will in turn significantly help in managing those tough questions from stakeholders.
For those interested in exploring this further, please reply below or get in touch directly.