Agile delivery: what could wait so the important work can finish?

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.

Continue reading Agile delivery: what could wait so the important work can finish?

Agility needs boundaries

Being agile means being willing to adapt. But what, exactly, are we willing to change?

Consider a team approaching a deadline with more work than it can finish. Should it extend the deadline, squeeze in extra hours, reduce testing or deliver fewer features?

That choice deserves a conversation before the pressure arrives.

Decide what to protect

DSDM, the Dynamic Systems Development Method, makes the trade-off explicit: fix time, fix cost and fix the agreed level of quality, then vary the scope.

Lower-priority requirements provide room to adapt. They can be deferred by agreement when the work proves harder than expected.

The aim is to deliver a useful solution within the agreed constraints. That requires clear priorities and enough flexibility in the feature list.

If everything is a must, there is nowhere for that flexibility to go.

Continue reading Agility needs boundaries

What the age of unfinished work can tell us

On Tuesday, we looked at a simple idea: a new Sprint does not erase the history of work already in progress.

So what can that history tell us?

Velocity shows how much estimated work a team completed in previous Sprints. Throughput counts the items completed over a period. Both tell us about finished work, but neither tells us how long a particular unfinished item has been in progress or has been waiting.

Continue reading What the age of unfinished work can tell us

The Sprint ends, but the work’s history does not disappear

A Sprint gives a team a useful rhythm. At its end, we inspect what we have achieved and plan what comes next.

But unfinished work does not become new work just because a new Sprint has begun. It carries its history with it.

Continue reading The Sprint ends, but the work’s history does not disappear

Where does completed work actually wait?

A Scrum team completes an Increment. What happens next?

If the answer includes, “It waits”, the team may have uncovered a wider problem in the delivery system.

Follow the work

Choose a recently completed Product Backlog item (PBI) and follow its journey beyond the team.

Where did it go after it met the Definition of Done?

Continue reading Where does completed work actually wait?