Delivery Team Meetings
- /
- System of Delivery
- /
- Structure
- /
- Product Line Team
- /
- Delivery Team Meetings
Sprint Planning
Backlog Refinement
Daily Standup
Agile Assessment
Sprint Demo/Review
Sprint Retrospective
Responsible Accountable Consulted Informed
Facilitator Accountable Consulted Informed
The purpose of the Sprint Planning meeting is for the team to agree to complete a set of the top-ordered product backlog items. This commitment defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.
Governance State: Story Ready
4 hours per month; ideally as one working session per month
R – Business/Capability Owner
A – Accountable Owner
C – Product Category Team, SMEs
I – Stakeholders
Timing: 15 mins
F – Product Specialist
Open meeting with announcements or updates; share meeting focus (planned discussions and decisions); validate that the appropriate information is available to have those discussions and/or make the anticipated decisions
Timing: 15 mins
Outcomes:
F – Product Specialist A – Product Specialist R – Delivery Team C – Product Owner
The Product Owner explains the larger product roadmap and discusses a goal for the Sprint that would be most impactful in accomplishing the near-term objectives. They recommend Product Backlog Items to accomplish those objectives. These would be User Stories from the “top” of the Product Backlog since the Product Owner has already aligned their Product Backlog with the Features priority. The Delivery Team will ask questions to understand these features better, and the Product Owner should be able to represent the value they bring to the end customer.
As the team understands the objectives, they should distill a singular goal for the Sprint to leverage as criteria for what stories to pull into the Sprint Backlog. The team collectively creates the Sprint Goal. The Sprint Goal is useful for focusing effort during the Sprint and reporting to stakeholders without overloading them with detail.
The Product Owner may guide the Delivery Team in selecting Product Backlog items supporting the Sprint Goal. As a rule of thumb, they should be prepared to discuss two sprints worth of backlog items.
Timing: 45 mins
Outcomes:
F – Product Specialist A – Product Specialist R – Delivery Team C – Product Owner
Once the team has agreed on the Sprint Goal, they decide what stories from the prioritized Product Backlog will achieve it and pull that work into Sprint Backlog. The team should use their historical velocity and forecast their capacity in the next Sprint to inform this commitment. Some factors to consider when forecasting capacity are days available in the Sprint (account for holidays), availability of team members (account for PTO), and percentage allocation of team members (account for any team members that are not fully committed to the team for this Sprint). Product Backlog Items that are too large to be completed in a Sprint might be broken out into smaller pieces or a smaller Story that does fit and can be pulled in.
Timing: 2.5 hours
Outcomes:
F – Product Specialist A – Product Specialist R – Delivery Team C – Product Owner
Having established a goal for the Sprint and identified Sprint Backlog Items to achieve it, the team must decide how to build this into a shippable increment that meets the Definition of Done. This conversation is much more tactical; the result is that the team should collectively understand, in detail, the steps necessary to build this functionality and meet the Definition of Done. These may be captured in tasks and should include testing details and other non-functional requirements. Tasks should be SMART (Specific, Measurable, Achievable, Relevant, Timeboxed). A “plan as you go” approach is also acceptable, but by the end of the meeting, work should be adequately decomposed for the next couple of days of work.
As this finer detail is broken out, the team may find things were bigger, more complex, or overly expensive than they initially thought and have to renegotiate the scope of the Sprint Backlog. The Product Owner helps clarify the value of these items so the team can make intelligent trade-offs. The Delivery Team may invite a subject matter expert to offer perspective on niched domains.
Timing: 15 mins
Outcomes:
F – Product Specialist A – Product Specialist R – Delivery Team I – Product Line Team
Review decisions and action items. Confirm RACI and timing for action items. Confirm RACI and timing for follow-on communications. Perform a brief retrospective on the session and decide what to do differently next time.
Backlog Refinement is a regularly scheduled meeting for the Delivery Team where user stories initially defined as part of the Story Writing and Story Mapping exercise and originally planned as part of Release Planning are further refined and updated for Delivery Teams to take work into a Sprint.
Governance State: Make Ready
1-2 Hours; 2-3 Times Per Week
R – Delivery Team
A – Product Specialist
C – Product Owner
I – Product Line Team
Prerequisite Work
Timing: 15 mins
F – Product Specialist A – Product Specialist
Open meeting with announcements or updates; share meeting focus (planned discussions and decisions); validate that the appropriate information is available to have those discussions and/or make the anticipated decisions
Timing: 15 mins
Outcomes:
F – Product Specialist A – Product Specialist R – Delivery Team C – Product Owner
Review Feature Definition, including acceptance criteria and Dependencies for all features on the agenda.
Outcomes:
F – Product Specialist A – Product Specialist R – Delivery Team
Update stories in ALM TOOL with a descriptive title, a description in a user story or system story format, and updated acceptance criteria. Split stories as needed and provide all necessary information for estimation.
Timing: 15 mins
Outcomes:
F – Product Specialist A – Product Specialist R – Delivery Team I – Product Line Team
Review decisions and action items. Confirm RACI and timing for action items. Confirm RACI and timing for follow-on communications. Perform a brief retrospective on the session and decide what to do differently (if any) next time.
The purpose of the daily standup (also called the daily Scrum) is to share information about the work in the Sprint, coordinate with team members, and surface any impediments to completing the work. Team members make commitments to each other to achieve the sprint commitment.
Governance State: In Progress
15 Minutes Max; Daily
R – Delivery Team
A – ScrumMaster
I – Product Line Team
F – Product Orchestrator R – Product Line Team A – Product Orchestrator
Open the meeting with announcements or updates; share meeting focus (planned discussions and decisions); validate that the appropriate information is available to have those discussions and/or make the anticipated decisions
State the Prime Directive and do a safety check
Timing: 13 mins max
F – ScrumMaster A – ScrumMaster R – Delivery Team
During the Daily Standup, each team member answers the following three questions:
Most teams conduct the daily Scrum meeting by having each person answer the three questions in order. You answer all three, then the next person, the next, and so on. An interesting alternative that some teams find helpful is to talk through one Product Backlog item before moving on to the next (walking the Scrum board). In this way, an individual may give an update multiple times during the same meeting. Having the Scrum board in front of everyone is useful to facilitate the meeting.
Any impediments raised in the Scrum meeting become the ScrumMaster’s responsibility to resolve as quickly as possible. In cases where the ScrumMaster cannot directly remove these impediments (e.g., usually the more technical issues), he still takes responsibility for ensuring someone on the team promptly resolves the issue.
Timing: 1 min
Outcomes:
F – ScrumMaster A – ScrumMaster R – Delivery Team
Review decisions and action items. Confirm RACI and timing for action items. Confirm RACI and timing for follow-on communications.
The agile assessment helps us understand the team’s journey towards Basecamp outcomes. This allows us to make an informed coaching plan, providing data points for stakeholders to better understand operational conditions.
Governance State: N/A
1 Hour Max.; Every Two Weeks
R – Delivery Team
A – Coach/ScrumMaster
C – N/A
I – Transformation Leadership Team
R – Delivery Team A – Coach/ScrumMaster C -N/A I – Transformation Leadership Team
Timing: 5 mins
F – Coach/ScrumMaster A – ScrumMaster R – Delivery Team
Open meeting with announcements or updates and emphasize safety principle; share meeting focus (planned discussions and decisions); validate that the appropriate information is available to have those discussions and/or make the anticipated decisions.
Timing: 50 mins
Outcomes:
F – Coach/ScrumMaster A – ScrumMaster R – Delivery Team
Iterate through each of the assessment exit criteria, then discuss the competency measures for each exit criteria and determine if the assessment state can be changed based on the evidence available.
Timing: 5 mins
Outcomes:
F – Coach/ScrumMaster A – ScrumMaster R – Delivery Team I – Product Line Team
The Sprint Review is conducted with the Product Owner to ensure all acceptance criteria of the work completed have been met. Following the review, the team demonstrates completed functionality to showcase their work to interested stakeholders.
Governance State: Story Done
2 Hours Max; Every Two Weeks
R – Delivery Team
A – Product Specialist
I – Product Line Team
Timing: 10 mins
F – ScrumMaster A – Product Specialist
Open meeting with announcements or updates; share meeting focus (planned discussions and decisions); validate that the appropriate information is available to have those discussions and/or make the anticipated decisions
Timing: 1.5 hours max
Outcomes:
F – ScrumMaster A – Product Specialist R – Delivery Team I – Product Line Team
Timing: 15 mins
Outcomes:
F – ScrumMaster A – ScrumMaster R – Product Specialist C- Delivery Team I – Product Line Team
The team should capture the following metrics in the Notes section for this Sprint and all other “Enter on Last Day of Sprint” metrics to close out the Sprint:
Predictability
Quality
Timing: 5 mins
Outcomes:
F – Coach/ScrumMaster A – ScrumMaster R – Delivery Team I – Product Line Team
Review decisions and action items. Confirm RACI and timing for action items. Confirm RACI and timing for follow-on communications. Perform a brief retrospective on the session and decide what to do differently (if any) next time.
The purpose of the Sprint Retrospective is for the Delivery Team to meet every Sprint to review the team’s performance. The team targets one or two improvements to implement in the next Sprint.
Governance State: Story Accepted
1 Hour Max.; Every Two Weeks
R – Delivery Team
A – ScrumMaster
C -N/A
I – Product Line Team
Timing: 5 mins
F – ScrumMaster A – ScrumMaster R – Delivery Team
Welcome everyone, and review the purpose, agenda, and organizing tools. Review the Prime Directive and create safety.
Timing: 5 mins
Outcomes:
F – ScrumMaster A – ScrumMaster R – Delivery Team
Review action items from the previous retrospective.
Timing: 30 mins
Outcomes:
F – ScrumMaster A – ScrumMaster R – Delivery Team
Gather feedback regarding the previous Sprint (More of, less of, Same as)
Timing: 15 mins
Outcomes:
F – ScrumMaster A – ScrumMaster R – Delivery Team
The Delivery Team discusses the improvement candidates and decides which should be targeted by the team to implement in the next Sprint
Timing: 5 mins
Outcomes:
F – ScrumMaster A – ScrumMaster R – Delivery Team I – Product Line Team
Review decisions and action items. Confirm RACI and timing for action items. Confirm RACI and timing for follow-on communications. Perform a brief retrospective on the session and decide what to do differently (if any) next time.