Handing Impediments

Follow

Comments

3 comments

  • 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.

  • 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.

  • Avatar
    WillW

    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

    {{
      stack-bar-chart
        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
        series:
        - data: SELECT name, sum('actual hours') WHERE 'task status' < 'Done' and sprint = (current sprint)
          label:
    }}


    Seems to work well

Please sign in to leave a comment.