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

37731Re: Unable to Create Release Burndown

Expand Messages
  • mkg6_hotmail
    Apr 18, 2009
      The situation that you discover new stories as you implement them sounds very normal to me, especially if the domain is new for you and the business. You are basically chartering unknown waters.

      That doesn't mean that you cannot draw a release burndown. You simply add the newly discovered work at the bottom of your bar [http://danube.com/docs/scrumworks/pro/latest/reports.html#prodburnenhanced%5d. The forecast of when you are finished is at the point where the rate of work completed and the rate of work intersect. If they don't because you are adding the same amount or more as you are finishing you can also go back to the business and tell them.

      They should be glad because you provided them with an early warning and they can decide what to do before it gets out of control. Stick to the date and accept the scope, adjust the date to accomedate the scope, cancel the project altogether, add more people....

      --- In scrumdevelopment@yahoogroups.com, Michael Wollin <yahoo@...> wrote:
      >
      > I am unable to create a release burndown chart. The PO team does not have
      > specific a list of stories (story pointed or not) for our next releases.
      >
      > There are hundreds of stories and epics in the backlog captured from
      > customer workshops and design spikes and defects, only a few of which are in
      > play for this release. We have selected and ordered certain epics for what
      > we call our release roadmap. For example, we know that the next release will
      > support our first cut at something we call the edit workflow. What e don¹t
      > know is ALL the stories that remain to do for that bit of functionality. But
      > we time-boxed it to a release date if only to put a line in the sand.
      >
      > As we are implementing related stories in the current sprint, we are
      > discovering and writing new stories that will have to be done to support the
      > edit workflow and, hence, the next release. We will probably end up story
      > pointing some of these at the beginning of our sprint planning meeting and
      > including them in the next sprint.
      >
      > In summary, we do no know what the stories are in advance because we are
      > figuring out how things work. It¹s almost as if everything is a design
      > spike, but it¹s not that bad because we are finishing stories that add
      > business value and the design is emerging (along with the stories).
      >
      > Any suggestions?
      >
    • Show all 59 messages in this topic