I read that a valid output of a Daily Scrum is a list of impediments for the Scrum Master to work on. So, how are those impediments tracked for resolution?
I assume if they are big enough to be not resolved quickly, they are added to Product Backlog and may be discussed in the Sprint retrospective. However, I read in one article someone suggesting to use "Impediment Logs" to track impediments by Scrum Master. Don't think this a standard practice and can there be additional artifacts in Scrum apart from what the guide defines?
Thoughts?
--- Mohit Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
What you read about daily scrum is not right. First, if there is road blocks the whole team has to solve by itself. If some of them are because I misunderstanding or lack on knowledge about Scrum then Scrum Master is the point of reference. Saving Changes...
The "how" regarding impediment tracking is determined by the team - you might add them as details to work items which are impacted by them, create a separate "pain snake" to track them, or even use a traditional issue log.
However, the SM is NOT the primary owner of impediments - as Sergio indicates, the team should be able to resolve most impediments on their own. Those which they can't might be championed by the SM but they might have to escalate or engage others to help them get resolved.
Have you ever experienced or heard a Scrum Master using "Impediment Logs" or something similar to track impediments? I don't think every team is using Scrum the same way. It's tailored to suit the business need or product being developed.
So, would you say it should be okay if there are additional artifacts used apart from what the guide defines? Scrum guides states team can have additional ad-hoc meetings if required. Could the same be inferred about artifacts?
Regarding, SM is not the primary owner of impediments, I guess I am not sure yet. The guide states one of SM's responsibilities is "Removing impediments to the Development Team’s progress". In a way, the SM must own the responsibility to resolve them then, isn't it?
...
1 reply by Sergio Luis Conte
Aug 12, 2020 10:09 PM
Sergio Luis Conte
...
You can use what you like and best fits for your current situation, Scrum is a framework you must complete. You can call it impediment logs or what you want (for example issue log or action items logs perhaps you are using today). The only things you have to follow is what the Scrum Guide stated (again, just in case it applies for your situation).
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Aug 12, 2020 8:42 PM
Replying to Mohit Joshi
...
Thanks Kiron and Sergio.
Have you ever experienced or heard a Scrum Master using "Impediment Logs" or something similar to track impediments? I don't think every team is using Scrum the same way. It's tailored to suit the business need or product being developed.
So, would you say it should be okay if there are additional artifacts used apart from what the guide defines? Scrum guides states team can have additional ad-hoc meetings if required. Could the same be inferred about artifacts?
Regarding, SM is not the primary owner of impediments, I guess I am not sure yet. The guide states one of SM's responsibilities is "Removing impediments to the Development Team’s progress". In a way, the SM must own the responsibility to resolve them then, isn't it?
You can use what you like and best fits for your current situation, Scrum is a framework you must complete. You can call it impediment logs or what you want (for example issue log or action items logs perhaps you are using today). The only things you have to follow is what the Scrum Guide stated (again, just in case it applies for your situation). Saving Changes...
Andrew SoswaTechnology leader| Leading global financial institutionElk Grove Village, Il, United States
When I coach a team, they execute a hands-on project. Usually, they know the methodology and continue uninterrupted. Sometimes, I stop them for a "Learning session" and tell them to mull over on how their action now will impact them in the future.
About the process... I keep separate "Issue log" and "risk log." Both are reviewed with the team and PO during Backlog Refinements. If the PO or entire team decides that it needs to be fixed, it is added to Backlog. If not, it is still safe in the log.
This is not very Agile-y but Jira Scrum's backlog is not the best place to keep open (or worse - closed issues) while opening another Jira module for issues is sometimes too much governance.
If you do Agile by hand on sticky notes, Excel spreadsheets are your best friends anyway.
In my implementations, I had various additional events and artifacts, i.e. UX sessions, technical walkthroughs, Architecture docs, etc - whatever the need for the product/service is. But always with a mind that if I set up 40 hours of meetings for the team, they will not produce any deliverables (unless the meeting's decisions are deliverables).
Sometimes, we lose visibility of the goal of Agile and want to fulfill the methodology to the end. What about if Scrum does not clearly state what to do. We should not follow methodology blindly - we should follow the spirit of the law (er, Agile Manifesto & Principles). Saving Changes...
