Should Scrum master inform Product Owner about the issues?
We've faced a situation where one of the developers was unable to work for a whole day. Issue was mistake of someone responsible for accesses to the machines. Scrum master and team leader of the developer done everything to solve the issue, anyway it took whole day.
Scrum master made his responsibility and remove problems for dev team. The question is: should Product owner be "Formally" informed about that (we've been talking about it during daily but PO wasn't present)? What do you think about it?
Does the team feel confident that they will be able to achieve the Sprint Goal, even with the amount of time and effort that was required to remove this impediment?
Has the difficulty impacted the Sprint Goal, or anything else agreed with the Product Owner? He or she might need to manage stakeholder expectations accordingly.
@Thomas and @Ian hit on the main point. There is one other perspective. How does not informing the PO affect transparency? And will it impact the POs ability to trust the Development Team if they kept to themselves?
The question is: should Product owner be "Formally" informed about that
Scrum doesn't prescribe what you should do in this situation. Each team would need to work this out for their own context. If the team and organization embrace the Scrum Vaues (courage, commitment, focus, openness, respect), perhaps the answer becomes obvious.
Is there a relationship within the Scrum Team, that means informing the Product Owner may cause problems?
If there is a reluctance to share this information with the Product Owner, perhaps the roles are being fulfilled in an unhealthy way. Could it be that the Product Owner is managing the Development Team members, rather than allowing them to self-organize?
In a healthy team, team members will not want to keep this sort of thing secret, and if they think it is helpful to share it with the Product Owner, they will do so.
In my opinion, this issue should be mentioned during the Daily Scrum where the Product Owner is present. Along with the issue, the developer/team must tell what steps are taken to ensure that corrective actions are taken also mention if this is going to affect the sprint goal.
Courage to tell the right state of affairs within the scrum team creates a healthy working environment based on trust and respect which is essential for the success of the scrum team.
Ajay don't forget that Daily Scrum meetings are designed for developer's to 'synchronize' their work. It is a common misconception that DSM is a mean to report status of the project.
I agree with Ian.If it will impact your Sprint Goal then I guess you should be informing the PO.
But then again, your artifacts are supposed to be transparent and "available already. The PO should be able to see this beforehand without having being informed by SM.
Daily scrum is an event where the development team mentions their issues and impediments. Hence this issue should come out during the Daily Scrum. It is not giving status to the PO but mentioning exactly the state of affairs among the participants of the Daily Scrum where PO can be present
Ajay Murali - you are assuming that the Product Owner is attending the Daily Scrum. Although I've found it helpful for the Product Owner to be in attendance to listen to what the development team is working on, to share his or her availability for the coming day after the team is finished, and be available after the Daily Scrum to answer questions or concerns, this is not required by the Scrum Guide. The only required participants in the Daily Scrum are the members of the Development Team. The Scrum Master may facilitate in some way, if asked by the Development Team, but even the Scrum Master is not required to be present.
For this particular team, they may not want the Product Owner at their Daily Scrum or they may hold their Daily Scrum at a time that is most convenient for the Development Team but not for the Product Owner. Regardless, it sounds like the Product Owner is not in attendance in the Daily Scrum.
It still comes back to the same question: What is the impact of this impediment on the Sprint Goals and/or completion of Product Backlog Items selected for the Sprint? The answer to this question would determine how important it is that the Product Owner care about the impediment here and now. It should come up in the Sprint Retrospective as well, so the Product Owner can learn about it then, as well.
As per my opinion, If the self organized team resolves the problem and there is no impact on Sprint goal, PO should not be informed. This also calls for updating/prioritizing sprint backlog.
However such concern needs to be discussed in retrospective meeting to identify the root cause and identify solution for stopping such events in future.
Just a note, Daily Scrum is for development team.