Scrum Master prepares a PTA-S before each Meeting
PTA = presented in 5 minutes at the beginning of the Meeting
S = presented at the end of the Meeting, time-box to 5 minutes/hour
Summary = Notes taken by the Scrum Master during the Meeting, when Agenda Items are discussed. Makes sure everyone is on par with what was discussed and potentially shareable with non-participants.
If anything come up that is not in the Agenda, take note of it in a Parking, to be discussed afterward.
Author = Michael de la Maza in “Robust Scrum Master Training” (Udemy)
Sprint Review Meeting
The Sprint review meeting should include the following:
Attendance and participation of the Scrum Team, product owner, and invited key stakeholders.
The Product Owner should report the items in the Product Backlog; what backlog items have been done and what have not.
The development team discusses what went well and the problems they experienced. They should also inform the group what they did to resolve the problems.
The development team demonstrates their completed work while answering questions about their increment.
The product owner leads the discussion on the Product Backlog as it currently stands. They set projected completion dates based on the progress of the Sprint session.
To give valuable input to the Sprint planning, the entire group establishes the next steps during the Sprint review meeting.
This is a time to review potential changes in the marketplace, the valuation of the project and what areas are considering to be the most valuable. The next steps should also be outlined.
Review the timeline, budget, potential capabilities, and marketplace to determine the next anticipated product release.
By the end of the Sprint Review, revisions should be made to the Product Backlog to better define probable backlog items for the next Sprint session. The Product Backlog can be adjusted completely to introduce new opportunities.
Focus on the End User
Involve the Product Owner
Understand Group Dynamics
Author = Luís Gonçalves
What is a Sprint Review?
Agenda for a Sprint Review
Product Owner identifies what has been done and what has not been done
Development Team talks about the Sprint:
What went well
Problems that arose
How they solved those problems
Demonstrates completed work/Product Backlog Items
Answers any questions
discusses current snapshot of Product Backlog and Roadmap
projects likely completion dates with various completion rate (or velocity) assumptions
All attendees then discuss previous agenda items and how they affect what to do next.
The Sprint Review also provides vital input into the impending Sprint Planning Meeting.
Tips for a Good Sprint Review
It is not a best practice to use the Sprint Review as a signoff or user acceptance meeting
Make the demo an informal one, maybe even done on a developer’s machine, but make sure that it is visible by all at the meeting (project it onto a big screen if need be)
Spend no more than 1 person hour preparing for the demo
Remember that a Sprint Review is much more than just a demo, also review the upcoming sprint and the results of the previous sprint on the overall release plan and product roadmap.
Time-box it to 1 hour per week of Sprint length (i.e. 2 week sprint = 2 hours, 4 week sprint = 4 hours, and so on)
Different teams will have differing needs as far as how much detail to go into during the Sprint Review. Tune your approach according to the needs of the attendees.
Have your Product Owner play the “lead emcee” role in the Sprint Review
Have the ScrumMaster be a silent observer in the Sprint Review. Ok, maybe not a silent observer, but at least a role where they only get involved in the review if it’s necessary to clarify Scrum roles, rules, or principles.
Treat all feedback as welcome feedback, especially from stakeholders
Treat the Sprint Review as if you were doing a focus group on your just completed features. Be curious about any hint of feedback, and ask for suggestions from everyone (including developers) on how to gain more value from the current and future features.
Never say never to a new feature or enhancement request. Always put it on the backlog. It may go way down in priority on the backlog, but put it there. You might word the backlog item slightly differently than the suggester did, but put it there. Try to word it as a request for functionality or request to solve a problem (“the what”) rather than a “do it this way” command (“the how”).
Any feedback that results in changes to be implemented is a new Product Backlog Item
Make sure the right stakeholders are present. Generally speaking this is a responsibility of the Product Owner (Provides vision) and the ScrumMaster (Resolves impediments).
Author = Robin Morgan (LeapFrog Systems via Medium)
Article on the four scrum ceremonies, delving into their purpose, attendees, and tips & tricks to make them most effective.
The four scrum ceremonies are:
1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospective
Author = Alexa Huston (Digital Project Manager)