Handing Impediments




  • Avatar
    James Tomkins

    We are just looking at this also.  My intention was to define a card type of 'Risk' detiling the type of Risk that could occur during development and then create a card type of 'Risk Occurrence' to record when a risk actually occurred causing some sort of impediment with details of its impact and path to resolution.  This would then also be able to notify product owners on creation.  Would be keen to hear how others have approached this.

    Comment actions Permalink
  • Avatar
    Chris Leon

    The way that we think of blockers is that if something is a blocker, we're going to work on a patch for it.

    We have a Release tree, set up as Release->Patch->Story.  So if something is so bad that we need to patch for it, then you create a patch, and schedule the story on it.  Then on the overview page we've got a simple table, showing all Story cards that are in a patch and aren't closed.  It's not a big orange post it, but it does the job for us.

    Comment actions Permalink
  • Avatar

    Thanks for the feedback.. We trialed an impediment task type for a sprint, but have changed to a dedicated card.

    We now have the following card tree

    Release > Sprint > Story > Task > Impediment > Defect

    The impediment has a custom card property of actual hours and we show all open impediments with the hours impeded on the overview page.

    h2. Outstanding impediments

        conditions: type = impediment
        cumulative: false
        labels: SELECT DISTINCT name where 'task status' < 'Done'
        chart-width: 900
        plot-width: 700
        chart-height: 500
        plot-x-offset: 100
        - data: SELECT name, sum('actual hours') WHERE 'task status' < 'Done' and sprint = (current sprint)

    Seems to work well

    Comment actions Permalink

Please sign in to leave a comment.