Involving the stakeholders during the sprint
Hello all,
Currently I am in a discussion with fellow developement team members about involving stakeholders during development in a sprint.
The case:
Some sprints ago we had an user story to create some kind of formula and show it on a web page. This formula is pretty complex but at the end of the sprint we had the formula correctly implemented. The tests were all green and the product owner approved it and was released into production. So far so good. After a while the stakeholder complained that the formula was not correctly shown on the web page. The stakeholder provided us with an excel sheet that should contain the correct values. The product owner created a new userstory and we picked this up in the next sprint. After evaluated the implemented formula we are sure that the formula is implemented correctly however the provided values on the excel sheet does not match with the formula. The conclusion is that either the formula is not correctly provided to us or the excel sheet does not contain the correct value.
Should we as development team members involve the stakeholder in the case above to help and find out what the problem is? And after finding the problem implement it in this userstory?
Note: Since the formula is pretty complex finding the problem can take a long time
Guido,
The Product Owner should have sole responsibility for representing the stakeholders with the team and ensuring that the team is working on the correct items to maximize their contribution to the business.
From your previous example, the Product Owner represented the business value to the team, the team created the work product according to the Product Owner's wishes, and the work product was released into production. A stakeholder then noted that the work product was not what they wanted.
Was this situation ever discussed during the Team Retrospective, to determine why the business need wasn't communicated correctly, and to discuss how to avoid similar situations in the future?
It seems there is value in not only inviting the stakeholder to the grooming sessions, but also inviting the stakeholder to the Sprint Review.
If there is still a disconnect between the team and Product Owner around story understanding, this should be escalated to the Product Owner for discussion. The team should not communicate directly with the Stakeholder regarding this issue.
I agree.
Product Owner is responsible for taking care of this however Dev team can support him in grooming the work where ever required.
Regards
Sanjay
> Should we as development team members
> involve the stakeholder in the case above to
> help and find out what the problem is?
No, because product ownership is not a committee. The PO must be the arbiter of product value and how it is represented to the team. The problem/contradiction must be explained to the PO as soon as possible so he or she can liaise with stakeholders and resolve it.
Involving this particular stakeholder should not be done on team initiative - *without consulting the PO first*.
The goal of the team is still to create high value products, and find ways to do this as effective as possible. So yes, according to the rules the PO should work with the stakeholders to get the requested value (formula) right, so the team can build it without needing the stakeholder. But in this situation it appears pretty complex and there is one domain expert that knows exactly how it should be. Invite this expert to the Sprint planning and you are still within the rules. :-)
Insisting on keeping the PO in between is not good for the right communication to happen. PO becomes bottleneck, not good.
Ruud, while we certainly want to promote the right communication, I'm not certain that I'm in agreement with your suggested approach.
I do not see the value of involving the Domain Expert in the Sprint Planning session, if they have not been involved in grooming sessions during the sprint. The Product Backlog Refinement efforts are where their domain knowledge is most needed, not in Sprint Planning where (hopefully) stories that already meet the Definition of Ready are discussed further, and the business makes the sprint offer to the team.
The team may desire the Domain Expert to be involved, for a number of reasons (mitigating identified impediments). However, if this involvement is not coordinated with the Product Owner, then there is serious risk of harming the PO/Team relationship.
It is up to the Product Owner to work with the Domain Expert to understand the issue and communicate it effectively to the team. It is up to the Product Owner to identify whether this Domain Expert needs to be invited to grooming sessions with the team. Allowing the team to try and work with whomever makes the most "sense" simply undermines both Scrum and a healthy relationship with their Product Owner.
Timothy,
I guess we're on the same line, only you express it more clearly (even reading back my own answer I see I missed some explicitness in my assumptions). Of course never involve an external (to Scrum Team) stakeholder without going through the Product Owner. And having this stakeholder present in sprint planning to explain the complex details is in my opinion still valid, if it helps creating the right Sprint Backlog, and if this could not have happened if this person were not present.
If it can be made clear to the team in refinement sessions, all the better. I understood this was such a complex case that even consulting this stakeholder during the sprint might be useful.
I like Scrum rules, but I like the Agile manifesto better: Individuals and interactions over process and tools. But as a devteam member bypassing your PO in order to get the 'right' result is a definite no-no (and 'right' between quotemarks because: who determines what is right? the PO).
Cheers,
Ruud