Alright, let’s dive into the joy-filled universe of Agile meetings—those carefully orchestrated gatherings where we pretend to have control over the chaos that is software development. Today, we’ll walk through every essential meeting within a two-week sprint cycle at our beloved Perth Panthers, who, by now, are practically Agile legends. Each sprint kicks off bright and early on a Monday—because everyone loves Mondays.
Before we jump into the meetings, let’s set the stage clearly. Each sprint lasts exactly two weeks, starting every second Monday, and involves a dedicated team including a Scrum Master/Project Manager, Business Analysts, Functional Consultants, Power Platform Developers, API Developers, Testers, and our indispensable Subject Matter Expert. It’s crucial to organise roles, responsibilities, and timings upfront—trust me, sorting this out pre-project is much better than trying to herd cats mid-chaos.
Here’s a detailed breakdown of each essential Agile meeting, including its purpose, who owns it, and who should attend:
Sprint Poker Meeting (Story Pointing)
Owned by: Scrum Master
Purpose: This meeting ensures the entire delivery team understands the scope and complexity of the user stories being proposed for an upcoming sprint. It allows developers, testers, and consultants to estimate effort using a shared Fibonacci scale and opens up early conversations about risks, unknowns, or assumptions. It’s not about getting the number right—it’s about reaching a shared understanding of the work.
When: One week before Sprint Planning, typically lasting about 1-2 hours.
Who attends: Functional Consultants, Developers (Power Platform and API), Testers, Business Analysts, Scrum Master.
Purpose: This meeting aims to agree on the complexity and size of user stories.
Input: User stories provided by Business Analysts.
Output: Agreed complexity scoring (using a custom Fibonacci sequence, naturally), ensuring the team is aligned on story complexity before detailed planning.
Three Amigos Meeting
Owned by: Functional Consultants
Purpose: This session brings together three critical viewpoints—business, development, and testing—to ensure each story is crystal clear. It’s where requirements get sharpened, edge cases get flagged, and ambiguity gets stamped out. If Sprint Poker is about scoring the story, this meeting is about interrogating it.
When: Shortly after the Sprint Poker Meeting, before Sprint Planning. Usually lasts around 1 hour.
Who attends: A representative from Business Analysts, Functional Consultants, and Testers.
Purpose: Clarify the details, risks, and test scenarios for user stories.
Input: Scored user stories.
Output: Shared understanding of user stories, identification of risks, dependencies, ambiguities, and preliminary test scenarios.
Sprint Planning Meeting
Owned by: Scrum Master
Purpose: This meeting sets the stage for the sprint. The team collectively selects the stories they believe they can deliver, breaks them down into manageable tasks, and makes time-based commitments. It’s also the point where velocity, capacity, and dependencies are balanced—often imperfectly, but always with best intent.
When: One week before each sprint starts, usually lasts 2-4 hours (or until people start eyeing the exit).
Who attends: Scrum Master, Project Manager, Business Analysts, Functional Consultants, Developers, Testers, Subject Matter Expert.
Purpose: Finalise what the team will achieve in the upcoming sprint and create actionable tasks.
Input: Scored and prioritised backlog items from Sprint Poker and Three Amigos sessions.
Output: Committed user stories, detailed task assignments, immediate initiation of Story Design and Test Build tasks.
Daily Stand-Up (Daily Scrum)
Owned by: Scrum Master
Purpose: This is the daily checkpoint where each team member shares what they did yesterday, what they’re doing today, and whether anything’s blocking them. It’s about synchronising and staying on track—not diving into detail. Keep it quick, keep it focused, and save deep dives for after.
When: Every day, at the start of the day. Strictly timeboxed to 15 minutes.
Who attends: Scrum Master, Functional Consultants, Developers, Testers.
Purpose: Quickly review progress, highlight blockers, and maintain team alignment.
Input: Progress updates, today’s goals, issues or impediments.
Output: Clear daily action plan and rapid issue resolution or escalation.
Mid-Sprint Planning Meeting (for next sprint)
Owned by: Scrum Master
Purpose: This meeting helps the team get a jump-start on the next sprint by validating and preparing stories early. It’s an opportunity to review scoring, double-check priorities, and get story design rolling in parallel. It creates breathing space for upcoming sprints—and reduces mad scrambles later.
When: Day one of the second week in each sprint (halfway point).
Who attends: Scrum Master, Project Manager, Business Analysts, Functional Consultants, Developers, Testers.
Purpose: Prepare and confirm stories for the upcoming sprint.
Input: Initially prepared and scored user stories.
Output: Confirmed and finalised backlog for the next sprint, initiated Story Design tasks.
Sprint Playback (Sprint Review)
Owned by: Project Manager
Purpose: This is where the team shows off what’s been built to stakeholders. It’s not just a demo—it’s a feedback loop. What’s working? What’s missing? What should we pivot toward? It validates the sprint outcomes and informs what gets added or reprioritised in the backlog.
When: Last Friday of each two-week sprint, usually scheduled for 1-2 hours.
Who attends: Entire project team, stakeholders, sponsors, and interested parties.
Purpose: Demonstrate the outcomes of the sprint and gather feedback.
Input: Completed tasks and functional software.
Output: Demonstration of completed work, stakeholder feedback, adjustments to the backlog, and documentation of sprint outcomes.
Sprint Retrospective
Owned by: Scrum Master
Purpose: A candid, team-only meeting to reflect on how the sprint went—no sugar-coating. This is the space to praise what worked, acknowledge what didn’t, and agree on how to improve next time. It’s how we grow sprint by sprint, instead of running into the same walls with increasing speed.
When: First Monday of the new two-week sprint, lasting about 1-2 hours.
Who attends: Scrum Master, Functional Consultants, Developers, Testers, Business Analysts, occasionally Subject Matter Expert.
Purpose: Reflect on the previous sprint to identify improvements and ensure continuous improvement.
Input: Team feedback on processes, successes, and failures from the previous sprint.
Output: Actionable improvements, enhanced processes, and morale boost.
Backlog Refinement (Ongoing, Weekly)
Owned by: Business Analysts
Purpose: This is where chaos is tamed before it hits the dev team. The BAs, often with help from testers and consultants, refine stories so they’re ready to score and plan. Stories get split, clarified, or killed—and the backlog stays healthy, actionable, and aligned to the product vision.
When: Weekly sessions lasting about 1 hour, typically mid-week.
Who attends: Business Analysts, Functional Consultants, Developers, Scrum Master, occasionally Testers.
Purpose: Continuously refine and prioritise the backlog for future sprints.
Input: New user stories, feedback, and clarification requests.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are as essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.