General Discussion

General discussion on using Mingle including questions and tips

This is a public Discussion Area  publicRSS

Post

    weswilliamz
    Overlapping ReleasesAnswered
    Post posted December 21, 2011 by weswilliamz, last edited February 9, 2012
    678 Views, 3 Comments
    Topic:
    Overlapping Releases
    Body:

    Given: Card tree of: Release - Iteration - Story

    When: I have an iteration that has stories from two different releases

    Then: ??? What are people doing in these cases

    ----------------------

    What I am doing now (which I am not satisified with)

    Then: I have an Iteration for each release that have the same start and stop dates

    And: I temporarily have two iteration views for tracking

     

    ----------------------

    I have the case at the end of each release where I have one iteration in which the team is generally working on a few small defects/ui tweaks for the current release but mostly focusing on stories for the next release. It causes me a few issues. 1) Multiple iteration cards that represent a single physical iteration in the real world. 2) For real metrics I need to combine the data from the two iteration. 3) a bit confusing but not overwhelming.

    Ideally we would have no defects but we are not there yet, we still need an iteration of stabilization.

    Ideas for a better way to visualize this situation?

     

    Thanks,

    Wes

    Best Comment

    Chris Leon
    posted January 9, 2012 by Chris Leon

    We do this with two trees:  Release->Release Patch->Story and Iteration->Story.

    Comment

     

    • Chris Leon
      posted January 9, 2012 by Chris Leon

      We do this with two trees:  Release->Release Patch->Story and Iteration->Story.

    • Ron
      posted January 30, 2012 by Ron

      We've been discussing this as well and are moving to a model similar to Chris.

      Release >Feature > Story and

      Iteration > Story

      The reasoning behind having 2 seperate trees is that Iterations are time based (weekly) while Releases are deployment based, at least in our case. As a result we could potentially have releases that bridge iterations and iterations that bridge releases depending on the needs of the customer.

    • weswilliamz
      posted January 30, 2012 by weswilliamz

      thanks for the ideas, I think two trees is more complex for my simple situation which generally has one week of overlap and minimal work on the previous release.