3

I am facing a problem of registering the impediments in one place from several projects that we are running at the company.

What I have tried

  • another Jira board for product owners to create issues meaning the blockers/impediments we are facing and then moving it to different stages - did not work out really well because the POs were forgetting to move the issues standing for impediments on another board on the regular basis
  • manual reports during biweekly meetings (this is what we are currently using) - difficult to maintain, it is not automated, gathering of information has to be planned in advance

This is the matrix that I am using during the biweekly calls with the product owners

  1. The impediments from the previous fortnight with their statuses and whether they have been already resolved or not.

  2. The impediments that we are having right now.

All of the information mentioned in the first two categories are viewed from the standpoint of which side is causing them: we as a company, our clients, third parties such as providers of products we have in use on our projects. Is anyone except us is causing impediments or blockers, is this side aware of this fact - that is another thing we look at. Then we analyze if the problems stop us from delivering everything else or are blocking us from testing the products or not.

I would like to know what are the good practices that you are using on your projects that help you store the impediments and keep them up-to-date automatically with little effort from the people involved (POs mainly). Also this would be a big plus if the solution you have could have auto-generation of reports on the impediments in pdf, excel or email notification formats.

Improve this question
2
  • 1
    Reports are generally where impediments go to achieve a sort of zombie immortality. Simply logging them is typically a CYA activity, especially as you're categorizing them in a way that's designed to shift responsibility/blame. What's the team's actual process for resolving the impediments?
    – Todd A. Jacobs ♦
    Sep 8, 2020 at 15:53
  • @ToddA.Jacobs at the company we gather information to have a sort of dashboard with the statuses and to report to our majority customer as well. In my question I mention only impediments but in reality we get more: what has been done since the last update on each project, what will have been done until the next update. The whole process of reporting helps us understand where the next problem might come from. According to that we can redistribute resources among the projects. Also I do not deny that this is a CYA activity that provides information on why some projects lag behind the schedule.
    – chullspen
    Sep 15, 2020 at 11:01

2 Answers 2

Reset to default
2

I see Scrum terms here (PO, impediment), but in Scrum, impediments are addressed during Scrum ceremonies and it's usually the SM's responsibility to resolve, not the PO. (Unless these impediments are specifically to do with missing info from stakeholders?); and they'd be addressed within the team, not at a higher cross-project level. So I'm a bit confused about the context here.

In terms of Jira technicalities, you could:

  • define an Impediment type of ticket that had its own workflow <-- what would that workflow be? This gets to the comment above about what is the process for resolving impediments
  • have the POs file those tickets in their own boards
  • create a new board of only those tickets based on a Jira filter to use at your meeting
  • the impediments will be in the proper project so harder to overlook updating

In terms of agile principles, have you held a retro with the POs about this issue to see what they think is the best approach?

Improve this answer
3
  • The impediments initially are addressed through the dailies. But in order to have a sort of dashboard with all the projects and their statuses and problems they are facing we need to conduct an update. From there they are addressed on a higher level among POs and managers of the company so everybody is in sync, it is very important because we have some resources being shared throughout the company and also a number of our projects are dependent on one another. The impediments are resolved inside the teams but we need to be in sync and update our majority customer as well.
    – chullspen
    Sep 15, 2020 at 11:32
  • 1
    Thanks, that helps me understand. Sounds like you are doing some form of scrum at scale, so I added that tag to your post.
    – Vicki Laidler
    Sep 15, 2020 at 15:54
  • Actually the steps you provide in your answer sound reasonable. I will try to implement some ideas you mention. As soon as I get any results I will update this question and write a comment in this thread. I looked up "Scrum at scale" and I only found a product called scrum@scale that sells courses for Scrum. Therefore I am not entirely sure what you meant when you said that I am doing some kind of Scrum at scale. Could you please expand on that or better point me to the right source? Thanks.
    – chullspen
    Sep 16, 2020 at 14:26
2

Impediment log

Just like you have a backlog of items that you need to build for each product/project, each PO can manage an impediment log with items that need to be fixed or removed from the team's way. Depending on the tools you use, this impediment log can be handled just like the backlog of features, bugs, etc, with all the reports, email notifications that go with that. It's just another type of project information to report for each project, and thus you won't need to aggregate impediments in a different place for all projects.

You could also manage impediments in the product backlog, like any other product backlog items, but have them with a higher priority. This has however the disadvantage that people might treat them like other product backlog items and put them in the same bucket like other types of work that can be done later, or be selected for one sprint or another, etc. Normally you work on impediments in parallel with your development work, so having a different log for them makes that separation clearer than having different types of items in the product backlog.

Board with "Impediments" column

Another alternative would be o have one column in the working board labeled "Impediments" and make the work visible there, to everyone. If you work with Kanban, your board is persistent and the impediments get removed from the column when you fix them. If you work with Scrum, this has the disadvantage that you have to move the items into each sprint board (if you didn't manage to clear some impediment in the current one), since the Scrum board gets reset with each sprint. Either way though, the items are visible in the board with all the other work that you do and you can't ignore them since they are "in your face" all the time, like at daily meetings for example.

I prefer this approach with an extra column in the board of current work (no matter if filled with items from the product backlog or a separate impediment log, or they just appear there on the fly, as they occur) because it keeps things visible, transparent, and everyone accountable for the impediments, not just the PO.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.