Overstuffing Fixed Budget Projects Not New in Agile

Photo by Zach Graves

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:

  1. Define baseline product scope -- create the product backlog.  (Shows an image with different size stories contained in an oval.)
  2. Define additional scope (Shows more stories contained in a square with an arrow to add them to the baseline oval.)
  3. 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.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.