Loading ...
Sorry, an error occurred while loading the content.

Re: Burn down flat - what are we doing wrong?

Expand Messages
  • woynam
    Sounds like an interesting project. I worked on a similar monster mainframe migration project like this back in 2006-2008. I have a copy of our burn-up chart
    Message 1 of 17 , Jan 19, 2010
    • 0 Attachment
      Sounds like an interesting project. I worked on a similar "monster" mainframe migration project like this back in 2006-2008. I have a copy of our burn-up chart in the Files section of this discussion group (Burnup Chart Example.jpg). If you can't access it, let me know and I'll email you a copy.

      You'll see from the graph that we shared similar issues. We ultimately finished the project after 34 iterations. You'll notice that the final estimates (ideal days) were 2.5 larger than the original estimates. Very little of this was scope creep. The vast majority of the increase was due to our increasing understanding of the complex requirements encoded in the legacy assembler code. While we were able to eliminate some functions altogether, and simplify others, the entire business model was extremely complex, especially when dealing with the various error conditions, and failure scenarios.

      Obviously, the key to finishing is to get your velocity greater than the increase in project size, else you'll never converge. Once we ramped up to our full team at the 12th iteration, we started to make some headway. Of course, with more sets of eyes on the project, we were able to identify more requirements! :-)

      Ultimately, you have to work with the product owner to determine which "must have" features can be deferred until a later release. We've had several small releases after the initial large release.

      As for predicting an end date, if your velocity is fairly stable you should be able to draw a trend line and intersect the estimate. You may have to make a few assumptions about the increase in future work. For example, is the "undiscovered" work going to increase at the same rate, slow down, or (highly unlikely) flatten to zero? With each of these scenarios you can plot a different trend line. Looking at my chart, the trend at iterations 12 through 15 pointed to a completion at the 34th iteration if we assumed that the project estimate was going to continue to grow at it's rate at the time.

      Mark


      --- In scrumdevelopment@yahoogroups.com, "sakendrick" <scottakendrick@...> wrote:
      >
      > We implemented Scrum in July of '09 and have been making great progress on a major new release in the works. Exec management is always looking for a project release date for the larger project.
      >
      > My challenge is that because we figure stuff out as we go, we are adding more or as many stories (or points) to the release as we are completing, which is resulting in my burn down chart effectively being flat - meaning my release projection is infinity.
      >
      > Why are we adding more to the back log? Primary reason is that we have stories that are somewhat epic in nature, or at least the work is not clearly understood until we talk about in planning or look ahead meetings. Often what happens is that these stories get broken into multiple stories causing what I have called STory explosion. Another reason is that we find issues in production that we need to fix in this next release, but none of this is feature scope creep (in fact just the opposite - I keep having to cut features from the release).
      >
      > Since Scrum is meant to be iterative and not "figure everything out up front", how do you avoid this and get a real true sense of work remaining so that we don't keep adding stories to the release back log.
      >
      > What are we doing wrong?
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.