Less than or equal for trees?




  • Avatar
    Suzie Prince


    I am not sure if we can facilitate the creation of the grid in the way you want because we can not order the cards in a tree but I do have another suggestion that may help you get the grid you want.

    Are the Iterations all in the same Release? If so, you could limit the grid to the "Current Release" and then limit the stories to the states that you are interested in (e.g. in analysis through to in signoff) and then you will get all the cards with the status you want regardless of the Iteration but you do not get the cards in the states you are not interested in (e.g. new).

    This is the type of thing we do for some of our views and it works well for us. Maybe you could try that out and see how it goes?

    - Suzie

  • Avatar
    Michael Decleene

    Thanks, Susie.  This might work, though isn't ideal.  In my example, I care deeply about cards for next iteration that are in a "Not Started" state (since we should be picking them up for analysis), but don't care about "Not Started" cards for iterations further out (since I don't expect anything from them).  I could potentially create an "Awaiting Analysis" status and once an iteration move next iteration's cards to that status.  Will noodle on this.

    Thinking a little more deeply, what it feels like I'd really like is less ordering child notes and more the ability to get at parent node attribues from the children.  In other words, set a "start date" and "end date" on iterations, and be able to do something in MQL like: "type = story and 'Iteration>Start Date' is less than (NextIterationStartDate)"  i.e. get at the Start Date of the Iteration card as if it were a property of the Stories linked to that iteration.  This feels like a generally useful feature for trees--it would allow information to be recorded once at the proper level and be able to propagate down to the lower-level cards (the logical opposite of Aggregates).

  • Avatar
    Ian Bridson

    Inheriting properties of the parent seems like a good idea to me. I had to create separate trees when we had this issue with differnt areas working on cards in differnt iterations- BA tree for analysis, Dev tree (is the original planning tree), a QA tree and a UAT tree.

    I had different filters for each arrea and so for each card it could be in BA-iteration 28 for BA, iteration 29 for dev, QA-iteration 30 for QA, and UAT-iteration 31 for UAT view. The 'color by' was Story Status. This increased the complexity of trees, and i had to set the same card up for each of the 4 views but after that it looks after itself. The next challenge was seeing all the views together, and for that i had to get screenshots of the individual views onto a word doc :-( . Thankfully Snaggit helped me there.

    Still it proved very useful in highlighting which stories were behind on analysis for next iteration and which stories were going to be ready for UAT

Please sign in to leave a comment.