Strongly scoped but dynamically scoped

That tile doesn't fit

I’ve got a few thoughts about planning that I want to consider, but first, there’s a few bits of clarification I want to explore. I believe that many people, especially ones forged in the fires of fixed-price bids, are terrified of scope change (not just scope creep), because any change blows carefully constructed estimates out of the water, which is why every meeting, every email, every customer contact has to be evaluated in terms of the effect on the budget. Does this increase the estimate? Is this an addition to the scope?

And then we revisit everything left to build, and re-estimate it all, and provide a new project plan based on the new projections.

Or not. Because we’ve got other things we need to do as well as estimates, and we know there’s known unknowns and unknown unknowns, which we’re trying to minimise, but it means all the estimating we do will not provide the final plan, until the software has been delivered and we can do it retrospectively. What benefit do we gain from continual estimation, apart from the reassurance that we have a number, whether or not that number is accurate.

I like to try and think about the scoping problem (and therefore estimates) boils down to whether the project is weakly scoped or dynamically scoped. If the scope of the project, and its budget are clear, then it’s easier to make small adjustments within that framework. If the scope is unclear, as with many bids, every change is a big change and has the potential to throw everything off.

* Static scoping = scope and content defined up front, and cannot be changed later, except by additional scoped work (i.e. change requests). See also : waterfall.
* Dynamic scoping = scale defined up front, but scope defined JIT depending on changing needs. Each sprint will bootstrap its own scope, but scope in terms of number of sprints/dev-hours can be fixed, if the project is strongly scoped. Will be mapped JIT to available resources and ready-for-development artefacts.
* Weak scoping = no scope defined, or minimally defined, even within a sprint.
* Strong scoping = scope well defined either in terms of budget, or dev-days, with clear assumptions on ill defined areas, either indicating that those areas are subject to de-scoping, or growth will require scope to be redefined.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.