A great explanation about managing the importance of managing scope:
I’m sitting at dinner right now. I’m at a steak restaurant in California. And I just ordered a salad and a petit filet, which is 4 ounces (113 grams). But now that I start to think about it, a 4-ounce steak seems pretty small, and there’s not much petite about me.
So as soon as the waiter comes back, I’m going to change my order to a 6-ounce (170 gram) filet. That and the salad should fill me up.
And you know what? I bet that waiter is going to charge me for the larger steak even though my initial order was for the smaller one.
But, should he charge me? After all, I’m still ordering a steak. That hasn’t changed.
Of course he should.
It’s universally understood that the waiter should charge me for the larger steak if I change my order to that.
But this concept is a little fuzzier in the software development world, where changes like this go by a different name: scope change.
Agile teams are often requested (or told) to lock down a guaranteed date for a guaranteed set of functionality. And, equipped with the right techniques, agile teams can do this.
No, it’s not as agile as leaving both scope and schedule up in the air would be. But teams need to succeed within the environments they find themselves. And some teams are in environments in which they need to promise a date, deliverables, or both.
When doing this, it is vital that the team explicitly communicate critical assumptions, such as that team members are not moved off the project, that stakeholders answer questions promptly, and so on.
The most important assumption to communicate is that while stakeholders can change some of the functionality to be delivered, they cannot change the overall size of the functionality to be delivered.
This means that if a customer wants to add an 8-point user story, the customer needs to remove an equivalent number of points.
If I tell my waiter I want to switch from the petit filet to something equally priced, my bill tonight won’t change. But if I want the larger steak, there’s no way I should expect it at the same price.
By the same token, if a customer tells an agile software team it wants to change what will be delivered, the team shouldn’t charge for that, as long as the total scope doesn’t increase.
But stakeholders need to understand that when they do change the size of the scope, it comes with a cost because it will undermine the team’s ability to deliver everything expected by the date expected.
It’s important that these expectations be communicated clearly with stakeholders upfront if you want to succeed with agile
Mike Cohn
