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 :
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 –
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.