In Tuesday’s post, I explored why agility needs boundaries: clarity about what we protect and what we can change.
Now consider what happens when those boundaries meet a difficult deadline.
There is more work left than the team can realistically finish. What changes next?
Make scope the conversation
DSDM offers a deliberate approach: protect time, cost and the agreed quality standard, then vary the features delivered.
Try bringing that thinking into your next planning conversation.
Instead of asking how to squeeze everything in, ask what could we defer while still delivering a useful outcome?
The word ‘useful’ matters. Removing features makes sense only if what remains still meets the essential need.
Start with the outcome
Imagine a customer booking service approaching its launch date.
Customers need to find an available appointment, book it and receive confirmation. Saved preferences and personalised recommendations might improve the experience, but could follow later.
Ask:
- what must people be able to accomplish?
- which features are essential to that outcome?
- which could wait?
- what dependencies would make deferring them difficult?
A shorter feature list needs to remain a coherent solution.
Protect quality explicitly
Delivering fewer features should still mean delivering finished work.
For each retained feature, preserve the agreed standards for testing, accessibility, security and reliability.
A booking form without saved preferences can still be complete. A booking form that loses reservations cannot.
Be clear about that distinction before deadline pressure makes it tempting to blur it.
Agree who can make the trade-off
Scope flexibility requires more than a team’s willingness to adapt. It requires agreement from the people expecting the result.
In Scrum, Developers and the Product Owner can renegotiate Sprint scope as they learn, while protecting the Sprint Goal and maintaining quality.
Make that conversation concrete:
- identify lower-priority work early
- explain what deferring it would mean
- agree the decision with the appropriate stakeholders
- make the revised expectations visible
Moving an item to the backlog should not become a quiet promise to deliver it immediately afterwards. Its priority still needs reviewing.
Try one small experiment
At your next planning session, identify one feature that could wait if necessary.
Agree what would trigger that decision and who needs to be involved.
Then reflect afterwards: did we deliver a useful result at the agreed quality, within the time available?
That is a more revealing question than whether we completed every item on the original list.
