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
Comments
3 comments
We do this with two trees: Release->Release Patch->Story and Iteration->Story.
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.
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.
Please sign in to leave a comment.