Agile Development: No Sprint Is An Island!

by Kelly Waters

agile development no sprint is an island

One of the key agile principles is about fixing timescales and varying scope.

In DSDM (Dynamic Systems Development Methodology) these iterations are called Timeboxes; in Scrum agile management practice they are called Sprints.

For Business-As-Usual (BAU) changes to existing products, one Sprint may equal a release of the product. However for projects it's more than likely multiple Sprints will be required before the features have enough value to the user to be worth releasing.

In the case of projects, it's clear there must be some kind of release planning sitting over the individual Sprints. This is important to estimate how many Sprints are likely to be required before the product will be ready to be released.

Having done this release planning and worked out how many Sprints should be needed, probably doing some fairly high level estimating at the outset in order to secure project funding, individual Sprints cannot be run in isolation.

The danger if they are, is that any overhang - or personally I prefer to call it hangover :-) accumulates and creates a bow-wave effect towards the end of the project, and on some projects it's more like a tsunami!

Whilst the scope may be varied, and in agile development the scope should be varied, there does of course come a point when you simply can't vary scope any further without seriously undermining the basis of the original business case. And unfortunately it's at that point you're back to the good old-fashioned slippage, that is all-too-common and all-too-painful in so many software development projects using whatever methodology.

So how about BAU? Surely you can run individual Sprints in BAU, each leading to a release of the product? Yes, technically you can. But I say you shouldn't.

Just to clarify - yes, of course you can run individual Sprints each leading to a release of the product. But ideally you shouldn't run a sequence of Sprints in complete isolation, even in the BAU scenario.

The product owner, together with the product team and those responsible for the commercial results of the product, should ideally form an outline plan of sorts; a high level roadmap if you will. This is important as the basis for business planning, budgets, revenue forecasts, etc. And even if the planning is fairly unscientific at this level, there must be a clear business vision of the key drivers for the product over time, and this vision needs to inform the priorities of the Sprints.

See also:
10 Key Principles of Agile Development
Time waits for no man!
How can I be sure my project will deliver on time?