Your thoughts on our new processes/template

Follow

Comments

2 comments

  • Avatar
    Mike Wylde

    Your trees are close to those we use in our demo projects and those I’ve seen our consultants recommend to clients. The main difference is that we include story in the Delivery Tree.


     


    We have slightly different trees:


    Epic>Feature>story


    And


    Release>sprint>story>task>defect


     


    The differences are fairly minor and I don’t think they’d change the available functionality to any great degree.


     


    This structure seems to serve adequately allowing views for backlogs as well as WIP. We would always recommend transitions to move items across a wall. These trees allows stories to be moved across sprints and their defects will be moved as well (if your definitions say that a story cannot be finished whilst it has outstanding defects). If the wall permits defects can also be moved across sprints but in this case the relationship with the story is lost, perhaps something that you wouldn't want to allow. 


    One of the things to remember about Mingle trees is that all levels are not required, this means that a defect can be directly connected to a story (or a sprint) without there needing to be a task present.


    I’m confused by your blocker and workaround defects. Can you truly ship with a blocker defect? My understanding of a blocker is that it totally blocks a set of functionality so it would depend upon whether that functionality was important whether I could release or not whereas I would ship with a defect that had a workaround as all functionality could still be accessed.

  • Avatar
    Michael Green

    We use something similar -but also have a tree just for organizing requirements functionallity (feature tree)

















    Feature - Story tree Feature > Story > Task
    Planning tree Release > Sprint > Story > Task > Defect
    Test Tree Story > Task > Test Case > Defect

    We have a test tree and use defect cards assigned (hopefully) to test cases.  This way, when we create a defect on a story/task, the developer can also see the exact test case that was executed to experience the defect. 


    I'll note, for the Planning Tree, we very lightly (if ever) use the defect tied to anything but a sprint - as the defect is already tied to the task/story in the test tree.


    As Mike pointed out above, Mingle does not enforce tree parents to be required - so while we hope our defects are assigned to a test case, many times the test case isn't created when we find basic defects..


    here is an example in our Test Tree of a task with two defects, both assigned to a test case. 



     


    regards,


    Mike

Please sign in to leave a comment.