Every Scrum team has either asked other teams for help with deliverables review or has provided assistance by reviewing deliverables of other teams
This inter-team collaboration encouraged as it will in turn improve inter-team communication, speed of deliverable reviews and most importantly quality of deliverables
However before Product Owners can accept a deliverable as approved, we'll need to see that the team performing the review has actually invested time to provide constructive and actionable feedback, or we'll automatically assume that deliverable isn't to expected acceptance criteria
What does this mean in practice:
However before Product Owners can accept a deliverable as approved, we'll need to see that the team performing the review has actually invested time to provide constructive and actionable feedback, or we'll automatically assume that deliverable isn't to expected acceptance criteria
What does this mean in practice:
Scrum team being reviewed - help reviewers to help you:
a) Explain to the review team the intent behind the deliverable
b) Specify areas that must be reviewed in a structured way
c) Note what kind of feedback you need in order to have the deliverable approved
Team performing the review - provide full information in your reply:
a) What has been reviewed
b) What should be modified/updated/clarified, or
c) Why nothing should be modified/updated/clarified (less likely)
d) Recommend whether the reviewed deliverable should be approved or not by PO
Why should a team spend time to review other team's deliverables if they are not direct stakeholders? Our Company values statement says that Everyone serves: "Treat
everyone as a customer, internal or external, and make responsiveness part of your
personal brand. Build effective working relationships with a focus on being positive,
informative, actionable, and helpful."
Leave-me-alone type of replies such as "Approved", "We have nothing to add", "This is good", and similar won't count as reviews at all when doing Sprint review
