Tuesday, July 28, 2009

Scope Budgeting

A while back, I attended the talk Scope Is Not A Dirty Word given by business analyst Angela Ashworth and delivery manager Mark Coster from ThoughtWorks.

The centre of the discussion was "scope budgeting," which basically boils down to having the developer work with the user to manage scope within an iteration.

In many flavours of agile, the user writes a story, the developer estimates it, and then it goes into the backlog. It's only when the story gets pulled from the backlog and put into an iteration that the user and developer fully flesh out the implementation details. But at that point, they may find they have scope creep—that the implementation will take longer than the original estimate.

At this point, the developer has two options:

  1. Implement the story, even though it will take longer than originally estimated, pushing out the other stories, potentially dropping some off the end of the release.
  2. Talk to the user more. Let him know that the estimate has changed and why. See if together they can come up with a way to reduce the scope of the story to get it back down to the estimate.

Option 2 is scope budgeting.

I have to admit that I was actually very disappointed to hear this from ThoughtWorks.

I have never been part of an agile project, I've only read about it. My agile daydreams included how nice it would be to have the user prioritise stories from the beginning, understanding that not everything would necessarily make it into a release, thus avoiding one of the activities I've come to think of as churn—the developer and user constantly having to re-prioritise and re-think functionality as scope creep happens in order to try to fit everything in or to figure out what is best to leave out.

I suppose I can understand why scope budgeting is a good idea. And I can understand that having all the stories in an unchanging ordered list from the beginning of the project isn't really very agile at all.

But it's still tough to see my daydreams shattered.

The up side is that it highlights that both the developer and the user are in the same boat, working together toward the same goal. In waterfall, each is under pressure to "be perfect." The user should write down every single implementation detail at the beginning of the project and the developer should estimate every one of them down to the minute. Later, when they discover that a requirement was missed, the developer blames the user for blowing the project. When they discover that an estimate wasn't quite right, the user blames the developer for blowing the project.

At least with agile and scope budgeting, the focus changes from blaming to recognising that neither the user nor the developer can make a perfect plan at the beginning of the project—that they need to work together throughout to figure out how to create the most value.

1 comment:

  1. As a member of a product team though, you need to be really in touch of what kinds of things you're budgeting out of scope. It's very easy, due to release after release of scope budgeting, to start getting into a mindset where you're only delivering minimum ante functionality to cross off a feature.

    You've got to be careful here, and remember that as a product developer, you're priorities, your clients, and your work product are different than Thoughtworks'.