I just installed Mingle 2.0, and I’m very excited about a lot of the new features, in particular the tree view. However, the tree view is a little too inflexible for my use. Here are a couple of problems I’ve already run into, with suggested solutions.

PROBLEM: I had meaningful values in Sprint Parent Story ID from 1.1, but I couldn’t use this information to make my tree structure in 2.0. Instead, I had to manually go through my cards and recreate all the relationships that I’d already created once so 2.0 would understand them. (And no, it wouldn’t accept my naming Sprint Parent Story ID as a relation variable.)
SUGGESTED SOLUTION: Allow Mingle to infer relationships based on existing card properties.

PROBLEM: Some tasks were larger than they appeared during sprint planning, so I broke them down into smaller tasks. But there’s no way to show that on the tree (except by introducing a new card type), since tree view only allows exactly one card type to be present at each level, and only allows a finite number of levels.
SUGGESTED SOLUTION: Make it possible to remove constraints on what type of card can appear where in the tree. For some types of project, it is useful to have such a tightly structured tree as Mingle seems to want. For other types of project, it is useful to have the card tree accept an arbitrary acyclic directed graph. Mingle should support both usage patterns.

Hi Marnen,

There may be a couple misconceptions you have right now about how trees work. Some clarifications:

• Although you can only configure one type at each level of a tree, any card can actually belong to any one of it’s parent types. Thus, if my tree is called ‘Application’ and contains card types of ‘Feature’->‘Group’->‘Story’, the ‘Story’ could actually fall under ‘Group’, ‘Feature’ or under the root node of the ‘Applications’ tree itself. The configuration view puts the structure there as a guide, but you are not confined to those levels.
• There is no limit on the levels within the tree.

That said, you bring up a point about inferring relationships, which is definitely a great idea, but non-trivial in a system where people can have lots of varied structures. What we have now is a starting point, and based on feedback, we will iterate on the design, so we are glad to hear more about how you would like this to work.

In regard to your bringing over values from an old project using Sprint Parent Story ID. Were you tracking a card number in this property? You can actually do what you are talking about by first creating a tree with relationship ‘Story’->‘Task’ and bringing your stories in. Then you can use the Excel Import function or bulk property updates to attach your tasks to the stories in the tree using the old ‘Sprint Parent Story ID’ values for the relationships.

Please let us know if this helps clarify.

Adam—

Thanks for your reply. Based on what you’ve written, I don’t think I have any particular misconceptions about how trees work—they just don’t quite do the trick for me as currently implemented. Some particular points:

Although you can only configure one type at each level of a tree, any card can actually belong to any one of it’s parent types.

This is good to know, although not applicable to my current use case.

In regard to your bringing over values from an old project using Sprint Parent Story ID. Were you tracking a card number in this property?

Yes. It was in the Scrum template in Mingle 1.1, and I thought that that’s what I was supposed to do with that property. Since it was in one of the preconfigured templates in 1.1, I was quite surprised that the tree features in 2.0 couldn’t deal with it.

You can actually do what you are talking about by first creating a tree with relationship ‘Story’->‘Task’ and bringing your stories in.

Huh? How would that help? And what do you mean about “bringing my stories in”? If you’re implying that I should be reimporting my stories and tasks from a spreadsheet or CSV file, I’m not sure how that would help, as it seems to me that it would run into the same problem. Or is there something I don’t understand here?

FWIW, looks like I’m not the only one asking for this. See http://studios.thoughtworks.com/discussion/forums/6/topics/521 and http://studios.thoughtworks.com/discussion/forums/6/topics/554 .

Huh? How would that help? And what do you mean about “bringing my stories in”? If you’re implying that I should be reimporting my stories and tasks from a spreadsheet or CSV file, I’m not sure how that would help, as it seems to me that it would run into the same problem. Or is there something I don’t understand here?

Marnen

I would like to explain further how, by some simple manipulation of existing card property data (such as Sprint Story Parent ID in your example), you can have Mingle 2.0 ‘draw’ trees for you.

1. Create the tree in Mingle 2.0 e.g. for a tree called ‘Planning’ the configuration is ‘Release’>‘Story’>‘Task’
2. Use ‘Export to Excel’
3. You will see the newly created tree name and relationship properties in the export e.g. Planning Release Story
4. Indicate whether your cards should appear in the tree by using ‘yes’ as the value for Planning. There is no need to say ‘no’ if you do not want the card in the tree
5. For those cards that you want added to the tree, indicate any relationships you want to create by adding values to the relationship properties. For those relationships that you have already indicated in previously created properties simply paste the previous values to the new relationship property column
6. Now import again
7. During import there should be an option to import using the tree properties, select this option.
8. After importing your tree should have been updated to reflect the relationship values you indicated during import i.e. Mingle should have ‘drawn’ the tree for you

I know this is a little late for you as you have already recreated the relationships but hopefully this helps explain how previously created properties and their values can be used to create trees in Mingle 2.0.

In addition, we have captured your feedback to create recursive trees (e.g. ‘story’>‘task’>‘task’) and to ‘infer tree relationships’ as potential stories for upcoming releases.

I have the impression that the users and the ThoughtWorks people are talking about different things. It seems that we do not understand each other.
I like to try to get the use case more clear, or at least my use case. It is easier talking about concrete situations.

I am the Scrum Master of a team that uses cards for releases, sprints, stories, tasks and bugs.
We do not associate bug cards with other cards. We do associate task cards with story cards. We might associate tasks with bugs in the future.
We put stories, tasks and bugs in sprints.

For planning purposes, we like to have a tree relationship between releases and sprints, between sprints and stories, tasks and bugs, and between stories and tasks.
So with Mingle 2.0 we thought that we could model the envisioned tree like this:

Release > Sprint > (Story or Task or Bug) > Task

Release > Sprint > Story > Task
<pre>
but then we can put only Stories and Tasks in a Sprint (that is what I learn from this thread and that is what ThoughtWorks gives as a solution), but I cannot put Bugs in Sprints.

I look forward to ThoughtWorks' solution for this use case and I hope this use case helps discussing other aspects of this thread. 

I think modeling trees should be a topic at the next User Meeting.
  

Koen

I think I do understand what you want and there are definitely some pieces of the requirement the currently Mingle is not capable of. However, there are some things that can be worked out. Let me try to explain…

What you can do:

• You can create a tree Release > Sprint > Story > Task > Bug and this does allow the user to add Stories, Tasks and Bugs to a Sprint. It also allows relationships between Stories and Tasks, Stories and Bugs, and Tasks and Bugs.

• If you created a tree Release > Sprint > Story > Bug > Task this would allow the Tasks to be children of Bugs, which may be more desirable than Bugs being children of Tasks, but that would depend on your scenario.

What you can not do:

• What the structure Release > Sprint > Story > Task > Bug does not allow you to do is to create relationships between Stories and Stories, Tasks and Tasks and Bugs and Bugs. It also does not allow Stories to be children of Tasks or Bugs, or Tasks to be children of Bugs. (I understand this is a desired requirement for many people.)

I agree there are lots of different scenarios for use of trees and discussing this at the User Meeting is likely to prove useful in understanding these.

Thank you for your help in clarifying this issue. Suzie

Suzie,

Thanks for the explanation. I modeled the tree according to your advice. I populated the tree with cards. I will use it for a while to evaluate its usefulness.
I am, however, not completely happy with the current implementation of trees in Mingle. I cannot pinpoint the real issues yet, because I think that many of them interact with the generic nature of Mingle. The generic nature gives a lot of power to the user, but without some guidance the features might be used incorrectly, or misunderstood. Moreover, some users like to be able to put some restrictions on relationships (for instance not allowing story cards as children of release cards, but only of sprint cards in my use case). I have the impression that Mingle has not found the right balance yet between being generic and enforcing restrictions in tree relationships. With the tree in place now, I want to experiment, evaluate and think some more and then I will post my findings.

This discussion seems to be mostly focussed on the ability to have cards as children of other cards of the same type.

There is another use case mentioned in the initial suggestion/request (and re-raised here: http://studios.thoughtworks.com/discussion/forums/6/topics/574), which is to have a acyclic directed graph (not just a tree). This would require having cards able to have multiple parents irrespective of rules around the parent/child card type. Eg. A “story” card can be part of many “scenarios” (and “scenarios” have many “stories”), or a “task” can be required for many “stories” (and a “story” may consist of many “tasks”).