Change Control under DSDM Atern – using MoSCoW

During a presentation recently, I was asked how an agile project team manages change control. How, the questioner wanted to know, do you deal with new requirements, scope creep and what happens when requirements turn out to be a lot bigger than you expected?

Well I can tell you how Atern deals with it. But first there are a few things you should keep in mind :

  • An Atern project has at its heart the concept of fixing the end-date and ‘managing’ the features – the prioritised requirements list – in order to meet this date.
  • In order to deliver on time, we need contingency. That contingency is provided in the shape of non-essential requirements; our feature-contingency, if you will. These are the Could Have requirements
  • MoSCoW priority pertains to specific requirements and for a specific timeframe. A single requirement can be a Must Have for the project, a Should Have for the first Increment (Release), but only a Could Have for the first development timebox.
  • The business case for the project assumes that at least the Musts and the Shoulds are delivered on time.
  • As a rule of thumb, within any given timeframe, the effort associated with delivering your Must Have’s should not exceed 60% of the total effort in all the requirements for that timeframe. No more than a further 20% effort should be allocated to Should Have’s, with the remainder in Could Have’s.
  • I described in an earlier post how MoSCoW prioritisation works, but how is it exercised on the ever-changing project landscape?

    For ease of understanding (and my own arithmetic skills), let’s assume that you have 100 story points worth of requirements to complete within a given timebox. You do use story points, don’t you? Adding up the story points for all the Musts should total no more than 60, and the Shoulds a further 20, right?

    Okay, so we are merrily developing the solution, when our business ambassador mentions that he’s just thought of a new requirement. Okay, this is not too difficult. The process goes like this –

  • Get the team to size the new requirement. Give it a story point estimate relative to all the others in the same timebox. Let’s assume it’s a 5 point story.
  • Get the business to prioritise it. Assume it’s a Should Have
  • In the next timebox planning session, enter this new requirement into the pot of remaining stories to be considered, and get the team to select the stories they should be working on within the upcoming timebox. If that story is selected, it gets developed. If not, it won’t. Yet. Easy.
  • Now ask the business which lower-priority story gets sacrificed to make room for the newcomer? We have a fixed project team and a fixed amount of time, so we have to have a fixed amount of work. Adding new work means sacrificing another piece of work of the same size. Getting the business to select which lower-priority requirement gets sacrificed is a good way of ensuring that the business remains engaged and ultimately gets what they want.
  • Change the priority of the selected sacrificial Could Have to a Won’t Have for this timebox. Remember the priority only applies for a specific timeframe. It might well be that the story is still a Should Have for the Increment; it will just have to wait for the next timebox.
  • Ah, but what if the new requirement gets raised during an in-flight timebox? What if the Business Ambassador wants this requirement completed in the current timebox?

    The problem with doing this is that the newcomer needs to be estimated in order to compare it with the other requirements already in progress estimation happens collaboratively, right?

    Okay, so get the team to spend a minute or two after the daily stand-up to estimate the relative size of the new story. Now get the team to prioritise it and proceed with steps 4 and 5 above – choose the ‘sacrificial lamb’ and downgrade the priority. There is absolutely no point in continuing to work on something the business doesn’t want until later. Of course, if work has already started on it, you may need to choose another one if unpicking the work already done is not a simple matter.

    But what if you have so many of these new requirements that you don’t have any Could Haves left? Start sacrificing the Should Have’s of course. The essential principle is that you are always working on the highest priority requirements and this relative prioritisation needs to be a business decision.

    The trick is to recognise that when you are sacrificing Should Have’s from the Increment – i.e. they will not get delivered to Production during the current release – and make the change control a little more formal. Why? Because this means that the business case is potentially threatened. Someone a little more senior should be decided whether it’s okay to drop Should Have requirements from a release because it may mean that there is less benefit to be realised or the need to introduce costly manual work-arounds may negatively affect either the costs or benefits.

    About aterny

    Agile enthusiast and evangelist, DSDM practitioner, trainer and coach. Specialist in Agile project and programme management, governance and organisational transformation
    This entry was posted in Uncategorized. Bookmark the permalink.

    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