Why should Dev Team explain Tech Problems in Review?
Scrum Experts,
I see this line in Scrum Guide: Scrum Guide: "The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved"
Initially I was thinking that the problems that Dev Team should talk about are things like - how they didn't understand some business needs, how some new insight came up on a PBI, how they underestimated something, etc.
But, when I read the same in Agile Project Management by Ken, he clearly explains that "Dev Team describes the technical problems it had encountered and the way it had worked around them".
Why should the stakeholders be concerned about the technical problems?
Just my opinion, but this is not the first discrepancy between a Scrum book and an Agile book, especially an Agile book written 12 years ago.
It should be noted that the Scrum Guide does not open the Sprint Retrospective to stakeholders. It is a meeting between the development team, the Scrum Master, and the Product Owner.
What are your thoughts? Do you see any benefit in Product Owner awareness around technical issues occurring during a sprint, and how the team intends to address them going forward?
> Why should the stakeholders be concerned about the technical problems?
The Scrum Guide says that in a Sprint Review:
"- Attendees include the Scrum Team and key stakeholders invited by the Product Owner
...
- The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved"
A key stakeholder should add value to the Sprint Review, and to the team's ability in turn to deliver value.
Therefore, if the stakeholders invited by the Product Owner are not interested in these discussions, perhaps they aren't really "key" to the Sprint Review after all?
Stakeholders should be concerned, as occurrence of such technical issues & the way team resolves it has impact (positive or negative) on final product and delivery schedule.
Also there are cases where active stakeholder participation is required in resolving those technical issues effectively. For example, not having enough hardware or test units, network latency problem between remote teams etc. are technical issues & may require financial or other approvals to resolve.
Since sprint review is the formal meeting where everyone comes together, that is the best place for stakeholders to understand problems & ask clarification questions to team.
Thanks Timothy, Ian, Dipankar.
I am fully confused now.
Who could be the key stakeholders from PO eyes? That should be from business/user side - like legal, marketing, sales, service, product management, business department/operations heads, etc - basically all those who could provide 'feedback' on the value delivered and help with planning what is most valuable to do next. That is what I remember from some other book by Ken S or Jeff S.
Now, are we suggesting that there would be people from IT shop? And PO would invite them too? Besides the point that PO usually is not knowledgeable about IT leadership/governance, the Review may explode into unknown territory of discussions that don't add value - including talking about 'problems related to enablers of value'
Specifically to Dipankar - there are tech and domain experts that are invited by Dev Team during planning. And retrospective is the place where the issues you talk about are usually discussed - infra challenges, tooling, network - for the reason that those are 'problems related to enablers of value'. And it is precisely for that reason that DoD is adapted if needed to address any of these challenges or exploit any opportunity.
Forgive me if there is a misunderstanding.
But, need more help to understand this so I can guide my PO correctly.
> Who could be the key stakeholders from PO eyes?
The PO is accountable for value. Therefore the key stakeholders are the ones who are most likely to add value, whether it be in the Sprint Review itself or as a result of having attended it.
If someone isn't interested in the matters being discussed, that's a strong indication that their time would be better spent elsewhere. No stakeholder is kept prisoner, and if the PO invites such a person, they can just leave.
Another consideration for the PO is the signal-to-noise ratio of stakeholder attendance. Even if someone wants to attend, will he or she add value, or lead everyone off for a walk in the weeds?
>> Specifically to Dipankar - there are tech and domain experts that are invited by Dev Team during planning.
True. But in reality not everything will go according to plan & that's how technical or other issues will arise.
>>And retrospective is the place where the issues you talk about are usually discussed - infra challenges, tooling, network - for the reason that those are 'problems related to enablers of value'.
Retrospective meeting is scrum team's internal discussion & definitely technical issues can be discussed there to understand what went wrong & what better team can do in next sprint. However, not all technical issues are in control of dev team. If you are facing infra shortage, it will require extra budgetary allocation which will (often) need stakeholder approval. Since stakeholders will be present in review meeting, isn't it best place to discuss such issues face to face?
Another motivation behind discussing technical issues in review meeting is purely from "transparency" perspective - stakeholders should know what is happening in project. I don't think there is guidelines on which technical issues can be discussed in review meeting & which are not. It's the discretion of team, as long as transparency is maintained it should ok.
As for who are "stakeholders", scrum guide won't answer it directly, but you will find it in any standard project management book. PMI definition of stakeholder is : "people, groups, or organizations that could impact or be impacted by a decision, activity, or outcome of the project"
Who are such people or group, PO needs to decide for his project. In general you will like to call people who can positively or negatively influence your project and/or from whom you need support.
One important question is, what do we mean by technical discussions, an example would be helpful here.
The review is in general an opportunity for inspection and adaptation, meaning that these meetings are a great place for the team to get feedback from PO and stakeholders and to raise awareness on issues that are part of the project.
What is clear is that the PO and stakeholders should understand the relation between the topic under discussion and the value or goal that are affected by it.
It is also clear that the time in the meeting is short and is invaluable.
I always recommend our team to abstract more the problem and let deep technical discussions for offline.