Purpose: Provides the true measure of progress by showing working product increment
Attendees: PO, SM, Agile Team, and stakeholders invited by the PO
Facilitator: SM or PO
Preparation:
The review is prepared as a team (PO & team) to avoid PPT presentation in favor of demoing in a staging environment. If necessary, consider adding a ticket to the team backlog for review preparation
Agree on the DONE stories/enablers to be demoed, their order of presentation, and the presenter
Meeting Flow
Review business context and Iteration Goals
Demo and solicit feedback on each Story, spike, refactor, NFR
Discuss stories & enablers not completed and why
Identify risks, impediments, and share any insights that could impact a future planning/release
Revise team backlog and Team PI Objectives as needed
Recommended Practices
Invited Business stakeholders are present
The meeting is kick-offed by the PO who presents PI objectives addressed during the iteration with their corresponding iteration goals
Only DONE stories/enablers (passes DoD) are demoed in an environment similar to production if possible or as specified in the DoD
Agile team members are invited to contribute - to demo individual stories/enablers when independent business value
Business stakeholders are engaged: they are invited to provide feedback and share new insights
Remaining PI Objectives, PI scope, potential risks, and trade-off or reprioritization opportunities are discussed
The team's accomplishments are acknowledged by the invited stakeholders
The team is proud of their accomplishments and can celebrate
The team backlog is updated based on feedback and new insights collected
Stories/enablers not completed are moved to the backlog for reprioritization
Notes from HCD Observations
Observation Day
Duration: 1h
Attendees: Meaghan Hudak (SM), Rob Fay, Chelsea Brigg, Amy Castellani, Howard Montgomery, and Brandy Barnette
SM kicked off the meeting by asking who volunteer to demo
All team members demoed one after another
Team member demoed all their work including uncompleted work items
Questions were asked (mainly by 1 participant) and answered, and some dialogues took place between team member
The PO/PM acknowledged the team's accomplishments and provided feedback at the end of the meeting
It was great to see each team member demo
Opportunities missed:
Kicked off by presenting the PI Objectives or OKRs and team commitments or goals for the Sprint
Presents some of the metrics (burndown, CFD, ...) to show how the iteration went
Present insights from the sprint such as challenges, impediments, or blockers
Present all the stories completed that will be demoed
Provide an order of demo
Great presentations, good team enthusiasm, and energy: Team was proud of the work accomplished!
Iteration Retrospective
Foundation
Timebox: 1-1.5 hrs/2 weeks sprint
Purpose: Opportunity for learning, improving the product quality and team effectiveness by inspecting the current sprint execution (planned vs achieved commitments, values, and goals)
Attendees: Scrum/Agile Team, SM, and ideally PO, to maintain a safe environment for the team. However, other stakeholders can be invited by the team request
Facilitator: SM
Preparation:
The facilitator selects a retrospective technique to address the challenges experienced by the team during the sprint
The facilitator collectsobjective facts: data, metrics, observations
Meeting Flow
Get the participants focus on the activity
Gather the facts from the iteration: Data, metrics, objective observations
Define the problems to be addressed
Understand the root causes of the problems
Find solutions to the problem
Determine an action plan
Recommended Practices
Instill a safe environment for dialogue by sharing the Prime Directive “everyone did his best - no blame” + Las Vegas Rule
Start with an icebreaker to provide focus and outline the goals of the activity
Revisit the actionable improvement plan from last retrospective
Gather the facts from the current iteration (objective observation from team members, team member behaviors, work process, tools, Burndown, Sprint Report, Velocity Chart, CFD, …)
Make groups/clusters of similar statements
Define the core problem by adding problem statements as header on each of the groups
Prioritize the list of problems with, for example, a dot-voting activity
Understand the problem to solve by investigating the root causes with, for example, the 5 WHY, Fishbone Diagram, Pareto Analysis, ...
Find solutions for each root cause
Determine an action plan: Stories are added to the backlog to address the improvement, who is responsible/owner, and how success will be measured
Close out: Recap with highlights and takeaways from the activity
Attendees: Meaghan Hudak (SM), Rob Fay, Chelsea Brigg, Amy Castellani, Brian Flaherty
A team member mentioned extending the retro invite to other external stakeholders for transparency.
The retro is an activity exclusively for the internal team including SM and PO so that team members feel safe enough to engage, speak up, and discuss their opportunities for improvements.
SM did a good job kicking off and explaining the activity and the timebox for collecting the facts from the iteration. (12) mins were allocated for exercise and additional time for dot votes/ grouping
SM could have reminded the team when the timebox is at 50%, and 10% remaining. However, the SM asked if more time is needed near the end of the timebox.
SM did not share the facts from the iteration such as the Burndown Chart, Velocity Chart, or CFD
The status of action items from the last retrospective was not discussed. Are the previous action items in to do, in progress, done?
SM should clarify the criteria before each subsequence activity: for example criteria for grouping or voting before the activity is started. However, it get clarify when a team member asked the question
The tickets were discussed per priority of the vote (tickets with high votes were discussed first). However, there were good discussions but the opportunities to capture the action items were missed. EX: Discussion about confusing guidance from CMS leadership, internal peer-review request => No action items were captured
SM should pay attention to capture the action items in agreement with the team
Low team member engagement: only 2 out of the 4 team members were really engaged in the discussions. Another reason why the retro should remain exclusive to the team.
Team member did not have their cameras on for the majority of the retrospective making it difficult to understand the level of presence in the room.
During the retrospective, the team did a great job identifying areas of improvement such as introducing peer-review processes for feedback loop cycles from other team members and cross-functionality, but as mentioned there were no backlog items and commitment from the team.
Team members shared collaboration with LACE on commercial video, training, and identifying action items for PI Planning
The team discussed areas that are currently working such as World Usability Day which is great. however, the retrospective is an area where the team reflects on "How did we do during this Sprint" Did we meet our goals and objectives?
The team seemed concerned about the prioritization of HCD work and structure. Another reason for working agreements and clarification on DoR, DoD team norms.
The energy in the room was very low, retrospectives are also an opportunity to celebrate success and come out with new "ideas" that can improve the team's morale and collaboration.
ISG Playbook
APIs