Scope-Bound, Time-Boxed and Story-Centric Agile

Scope -Bound Agile

This is perhaps the easiest forms of Agile for a new organization to sell to their Product Managers.  In this you merely ask your product managers to rank their features and the stories within those features by ‘Customer Value’.  You then ask them to determine at what point in that rank order so-called ‘Minimum Marketable Feature’ (MMF), or ‘Minimum Viable Product’ (MVP) – I’m not making a distinction here, and for this purpose the distinction isn’t important nor useful.  Where the Product Manager draws the line under the stories in the ranked priority is then the ‘scope’.  Everything above the line is ‘necessary’, and everything below the line is ‘gold plate’.  The team pulls stories from the top of the backlog until the scope has been achieved, and then they move on to the next highest ranked feature.  You continue until all the work is done, or, if there is some kind of fixed release date, until you run out of time (in which case the lower priority feature you happen to be working on at the time is probably only half-done, so will be finished in the next release cycle).

This is particularly attractive for a variety of reasons.

1. There is minimal or no impact on the Product Management function.  This is the way that Product Managers have always worked – rank features by importance, have them built.   The only difference is in the serial nature of the design & delivery – but they never cared about that anyway – just as long as they get all they want!
2. The organization feels that it is always working on the most important thing at any given time.  As soon as one feature is done to the bare minimum, we move on to the next feature – we don’t have any luxury to even think about gold-plating.
3. The teams are running at full capacity all the time.  No sooner than one feature is done, the next is immediately started on.  There is no real pause at the sprint/iteration or even release level – from a feature build perspective those can be blown through as if they don’t exist.

This is particularly pernicious for a variety of reasons:

1. Where the line is drawn becomes very, very important to the organization.  Where that line on the feature list is drawn will determine the timeline (and therefore budget) of the project.  It therefore might well impact bonuses and all manner of things.  It becomes the discussion of Executive management where the executive team are dragged into discussions of whether to include that 3 point story or not.
2. Planning and approval of the project relies on knowing how long it will take (and therefore the cost).  But in order to do that, the organization needs to know the Minimum Viable Product of course.  This means that the prioritized backlog needs to be determined far ahead of time – during early roadmap design.  This is often a frustrating and futile process which doesn’t feel very Agile….and it isn’t – it sets everyone up to fail.
3. Lower priority stories are not gold-plating!  Gold plating by definition in any good project is ‘not included’.  Lower priority stories are stories that could be omitted while ‘something that works’ could be released to the market to be further built upon – they are really the most valuable from a market perspective – who pays top-dollar for ‘minimum’ after all!!
4. If the Product Manager is prioritizing stories because that impacts cost – then what is the role of the Business Analyst and UX Designer in choosing what gets built?  You set the organization up to disenfranchise your most creative and valuable people.  Believe me – this is very, very real.

Time-Boxed Agile

Any discrete body of work can be called a ‘project’ – it doesn’t really mean much except that the work can be isolated.  So for example a Quarterly release is a ‘project’ (its not really of course, Agile SDC is a process not a project…but anyway – topic for another blog!).  There is design, build, and release.  There are normal ‘project’ like things that go on – there is an Executive or other such approval, there is risk of unexpected things happening, changes that happen along the way, staffing that has to be thought of etc etc.  This doesn’t make it waterfall.  It can still be very Agile – the design phases are light and elaborative, the development is conducted through prioritized stories.  This is all just ‘normal agile’.  In that light, other ways of slicing up work into a project-type framework include –

1. Taking a Quarterly Release (which is a six iteration (where iterations are two weeks) and slicing it into two (so each half has three iterations).  Each half can be thought of in the same way as a mini release (except we don’t actually deploy code.   They are really just a time-box for administrative convenience so we can maintain light control (we don’t need to know or control the details of what is happening at the iteration level as far as Management is concerned, but we’d like to know more than just at the Quarterly level, so we (or the Project Manager etc)  CAN make changes in a systematic way as we/they need to.
2. Cutting up the release into any number of discrete Feature-based time-boxes.  These can also be mentally viewed as mini Feature Releases (except as above, we don’t actually deploy code either).

Both of these time-box techniques force the cycle times to be shorter than with a Quarterly release.  In Lean terms,  we have reduced the batch size down from several features that make up a release, to a single Feature ‘project’.  In my experience, features seem to take about two or three iterations to build, and about the same to design.  So we’ve taken the cycle time effectively from six months to about two months.  That seems like a step in the right direction.  Reducing cycle time increases overall throughput, reduces WIP, and increases the velocity of the feedback loop and lead time.  All VERY good things!

This is particularly attractive for a variety of reasons:

1. No-one actually cares how many of the stories are delivered.  The more the merrier of course – but the schedule and cost have been set in advance and are not dependent on the stories.  No more arguing in the corridor about that -point story!
2. The Business Analysts and UX designers can feel empowered to slice stories extremely thinly as they know that the thinner they slice the story, the more control they will have on the final product and the more feedback they will be able to get early on.  They are not incentivized to bury usability into the early MUST have of the development – a practice which inflates the overall risk of the project (and creates lots of topic for those corridor arguments).

This is particularly worrisome (for some) for a variety of reasons

1. If the teams start working into the ‘Could’s that looks like they are working on lower priority, gold-plating work.  The organization feels it can save money by stopping that development, and moving on to the next feature.  However, the COULDs are both the price you pay for the near certainty of always coming in on time, on budget, and are also often the most valuable from a market perspective (the icing on the cake)
2. If there is any hint that the Product Manager is really scope-bound then the organization is setting an ‘iron triangle’ trap – fixed time, scope and resources.
3. The time-boxes need to be set so that there is a reasonably high probability that all the SHOULDs are achievable.  This leaves some to believe that it is worth spending a lot of time estimating the SHOULDs in order to make project planning more accurate.  However, this misses the point that the COULDs are there to mitigate that risk – and this should NOT be done by trying to (futilely) get better estimates!

This is lifted straight from the DSDM 2013 Manual

Core Techniques of DSDM

• Time-boxing – Time-boxing is one of the project techniques of DSDM. It is used to support the main goals of DSDM to realize the development of an IS on time, within budget and with the desired quality. The main idea behind timeboxing is to split up the project in portions, each with a fixed budget and a delivery date. For each portion a number of requirements are selected that are prioritized according to the MoSCoW principle. Because time and budget are fixed, the only remaining variables are the requirements. So if a project is running out of time or money the requirements with the lowest priority are omitted. This does not mean that an unfinished product is delivered, because of the pareto principle that 80% of the project comes from 20% of the system requirements, so as long as those most important 20% of requirements are implemented into the system, the system therefore meets the business needs and that no system is built perfectly in the first try.
• MoSCoW – MoSCoW represents a way of prioritizing items. In the context of DSDM the MoSCoW technique is used to prioritize requirements. It is an acronym that stands for:

1. MUST have this requirement to meet the business needs.
2. SHOULD have this requirement if at all possible, but the project success does not rely on this.
3. COULD have this requirement if it does not affect the fitness of business needs of the project.
4. WON’T represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

Story-Centric Agile

Some have referred to this as ‘pure’ agile.  If a story is completely INVESTable, and you are effectively able to release ‘continuously’ then a single backlog of nicely prioritized stories can and should be executed sequentially without worrying about time-boxes or anything else.   You might need to do order of magnitude planning to see how much progress you can expect on any theme over time – for that T-Shirts and velocity should be perfectly adequate, but you don’t need a lot of advanced planning.  Because you are working on individual stories, your batch size is a story, and your cycle time can be incredibly short – almost sub-iteration if you are truly humming along.  “Think of an idea, prioritize it, bake It out, build it, deploy it “ in a single batch.  In this, iteration cadences are merely housekeeping functions to keep the beat going, but you could theoretically do without them and go straight to Kanban with daily deployments.  I get all this.  There are certainly certain types of activities – I’m thinking continuous improvement projects, or maintenance and support efforts – where the defining characteristic is that stories are pure INVEST, and can all be force-ranked against each other.  Let’s call this delivery method ‘Story-Centric’ Agile.

For that type of work, the level of Governance that you would apply for Project based (Scope or Time-boxed) work, is clearly not appropriate.  I’m not sure right now exactly how you would create a story-centric governance process (although block allocation as Jacob suggests, and the approach we’ve taken for bugs would certainly be a strong candidate), and I’m not sure how the two Governence models would co-exist – again we could use the Bugs model)…however I AM sure that we could come up with something that worked.  I suspect that Story-Centric work will be lighter on the upfront planning, and conversely heavier on the back-end reporting (think HPR Conversion project status) – because story centric initiatives tend to be longer running, and more fragmented