Overstuffing Fixed Budget Projects Not New in Agile
Photo by Zach Graves
I came across an explanation of how to handle change in agile fixed budget projects that I found rather telling; to protect the innocent, I won't post it directly. Here's what it said:
- Define baseline product scope -- create the product backlog. (Shows an image with different size stories contained in an oval.)
- Define additional scope (Shows more stories contained in a square with an arrow to add them to the baseline oval.)
- Removed stories to make room (Shows ONE story moved from the baseline oval to be outside the oval.)
The written steps make sense, but the visual shows what really happens: the work added to the scope is significantly more than what is removed. I remember having the same challenges with change requests and fixed budget projects in my pre-agile days, and I had to write contract addendums with additional cost in most cases.
A prioritized backlog and regular delivery of working software can help tremendously in easing the anxiety that drives scope creep, not to mention the ability to gain value early by releasing software that can help cover future development costs and provide better direction with customer feedback.
