Scrum Ceremonies: Advanced Best Practices Through Experience Sharing

(Interactive Session for Experienced PMs in Data Portal Projects)

Session Objective:

• Share best practices and challenges in Scrum ceremonies.
• Identify actionable improvements for our workflow.
• Learn from each other's experiences rather than a lecture-style approach.

Duration: 60 minutes

1. Warm-up: Common Struggles (10 min)
2. Sprint Planning Experience Exchange (15 min)
3. Daily Standup Real-World Problem Solving (10 min)
4. Sprint Review & Stakeholder Engagement (10 min)
5. Retrospective Game: What’s One Thing We’ll Change? (10 min)
6. Wrap-Up & Key Takeaways (5 min)

1. Warm-up: Common Struggles (10 min)

🎯 Goal: Set the stage by identifying real challenges.

🔹 Activity: Post-It Challenge (Virtual)

• Everyone writes one challenge they’ve faced in any Scrum ceremony in a shared doc.
• Group them into themes (e.g., “Unclear Estimates,” “Standups Feel Pointless,” “Stakeholders Don’t Engage”).
• Discussion: “Which of these resonate with you the most? Why?”

2. Sprint Planning Experience Exchange (15 min)

🎯 Goal: Improve sprint planning accuracy and efficiency.

🔹 Activity: "How Do You Plan?" Roundtable

• Everyone shares: “What’s your current approach to sprint planning?”
• Follow-up: “What’s one thing that works well? What’s one thing that could be better?”

🔹 Facilitator Prompts:

• How do you handle uncertainty when estimating dev days?
• How do you ensure GitHub issues are well-defined before planning?
• What’s your biggest time-waster in sprint planning, and how do you address it?

🔹 Group Synthesis:

• Identify 2-3 actionable takeaways based on what’s shared.

10 Best practices for sprint planning

10 Best Practices for a Highly Accurate and Efficient Sprint Planning Meeting

1. Prepare and refine GitHub issues in advance

   • Ensure every issue has a clear description, acceptance criteria, and is properly scoped before the meeting.
   • PMs and tech leads should pre-review tickets to remove ambiguity.

2. Base estimates on real past data

   • Use previous sprints to compare estimated vs. actual dev days and adjust accordingly.
   • Keep track of over/underestimations to refine accuracy over time.

3. Break down work into small, manageable tasks

   • Avoid vague or large issues—split them into smaller, well-defined tasks with a clear "definition of done."
   • If something is too uncertain, create a research/spike task first.

4. Account for non-development work

   • Include time for reviews, testing, bug fixes, deployments, and meetings in estimates.
   • Identify dependencies early to prevent blockers.

5. Ensure everyone commits to their estimates

   • Developers should actively participate in estimating dev days to ensure ownership.
   • Discuss and adjust estimates collaboratively rather than having a single person dictate them.

6. Use a structured format: priorities first

   • Start with the highest-priority issues and critical tasks.
   • Avoid wasting time on low-priority items that might not even make it into the sprint.

7. Balance workload realistically

   • Ensure no one is overloaded; leave buffer time for unexpected issues.
   • Consider developer availability (vacations, meetings, parallel projects).

8. Clarify dependencies upfront

   • Identify external blockers (e.g., waiting on data access, APIs, third-party inputs).
   • Assign owners to follow up on dependencies before they become problems.

9. Keep the meeting time-boxed and focused

   • Avoid unnecessary discussions—defer deep technical discussions to breakout sessions.
   • Use a facilitator (usually the PM) to keep things moving.

10. End with a clear sprint commitment

• Summarize the final sprint scope and expectations.
• Confirm that the team is confident in the plan and no major uncertainties remain.

3. Daily Standup Real-World Problem Solving (10 min)

🎯 Goal: Make standups more valuable and engaging.

🔹 Activity: The Standup Critique

• Split into small groups (or discuss together).
• Each group picks a real standup they’ve experienced and analyzes:
  • What made it useful?
  • What made it ineffective?
  • One change that would have improved it.

🔹 Debrief Discussion:

• How do you handle blockers in GitHub to avoid repeating “I’m still stuck on X”?
• What’s the best way to track unplanned work without derailing the sprint?

🔹 Actionable Insight:

• Have everyone write down one tweak they will try in their next standup.

Top 10 Best Practices for Effective Daily Standups

1. Keep it short (max 15 minutes)

   • Stay focused on key updates; avoid long discussions.
   • If deeper discussions are needed, schedule a follow-up after standup.

2. Use a structured format

   • Stick to: What was done? What’s next? Any blockers?
   • Keep it action-oriented, not a status report.

3. Make blockers the priority

   • If someone is stuck, immediately assign a follow-up or solution.
   • Encourage proactive problem-solving instead of just reporting issues.

4. Refer to GitHub boards for visibility

   • Update issues before the standup so the board reflects actual progress.
   • Move tasks through the board as part of the conversation.

5. Don’t just repeat what’s in GitHub—add value

   • Instead of saying, "I'm working on X," share insights like:
     "I'm working on X, but I ran into a dependency on Y—I'll sync with John after this."

6. Time-box each person’s update

   • If someone starts going deep into details, politely remind them to take it offline.

7. Encourage engagement, not just reporting

   • Ask: "Do you need help with that?" or "What’s slowing this down?"
   • Foster a culture where team members help unblock each other.

8. Rotate facilitation (optional)

   • Having different team members lead the standup keeps it fresh and engaging.

9. Be mindful of remote/hybrid setups

   • Ensure remote participants are actively included, not just listening.
   • Use video or async updates when needed.

10. End with clarity and action

• Confirm next steps for any blockers.
• Leave with a sense of alignment, not just a list of updates.

4. Sprint Review & Stakeholder Engagement (10 min)

🎯 Goal: Improve stakeholder involvement and feedback loops.

🔹 Activity: Reverse Brainstorming

• Question: “If we wanted to make sprint reviews completely useless, what would we do?”
• Generate bad ideas (e.g., “Only engineers talk,” “Show slides instead of a demo”).
• Flip them into positive best practices (e.g., “Ensure stakeholders interact with the feature live”).

🔹 Debrief Discussion:

• How do you get stakeholders actively involved instead of just listening?
• What’s a great sprint review moment you’ve experienced?

Top 10 best practices for sprint reviews

1. Focus on working software, not slides

   • Show live demos or working prototypes.
   • Avoid lengthy PowerPoint presentations.

2. Involve stakeholders actively, not just as spectators

   • Ask stakeholders for their input during the demo.
   • Encourage them to interact with the product in real-time.

3. Keep it interactive with live demos and discussions

   • Allow team members to walk through the demo and explain their work.
   • Have an open discussion on how features will be used or improved.

4. Showcase real user value, not just completed tasks

   • Focus on how the work contributes to the user's experience or business outcomes.
   • Align features with the goals defined at the beginning of the sprint.

5. Tie updates to sprint goals and business impact

   • Relate each demo to the sprint goals to show alignment.
   • Highlight how the work supports long-term business objectives.

6. Encourage open feedback and questions

   • Create an open environment where stakeholders can ask questions.
   • Make it clear that feedback is valuable and encourages continuous improvement.

7. Prepare in advance to ensure a smooth demo

   • Test the demo ahead of time to avoid technical glitches.
   • Ensure all required resources (e.g., accounts, devices) are ready.

8. Address challenges faced during the sprint

   • Highlight any roadblocks encountered and how they were addressed.
   • Share learnings and adjustments made throughout the sprint.

9. Keep it time-boxed and structured

   • Stick to a clear agenda and avoid veering off-topic.
   • Ensure that each team member has equal time to present their work.

10. Capture action items for follow-ups and improvements

• Note down feedback and action points that need attention in the next sprint.
• Assign owners to follow up on any unresolved issues or suggestions.

5. Retrospective Game: What’s One Thing We’ll Change? (10 min)

🎯 Goal: Ensure retrospectives drive real change.

🔹 Activity: "Speed Retrospective"

• Everyone writes down one improvement they implemented from a past retro that worked well.
• Share in a rapid-fire round.
• Discuss: “What’s one thing you wish retros could improve in our team?”

🔹 Action Step:

• Vote on one experiment to try in the next sprint retro.

Top 10 best practices for retros

1. Create a safe environment for open discussion

   • Ensure everyone feels comfortable sharing feedback, both positive and negative.
   • Foster a culture of respect and psychological safety.

2. Focus on actionable items

   • Identify concrete actions that can improve processes in the next sprint.
   • Avoid abstract feedback; make sure action items are specific and achievable.

3. Keep it time-boxed

   • Stick to the agreed time limit to maintain focus and energy.
   • Avoid dragging the meeting on with unnecessary discussions.

4. Mix up retrospective formats

   • Change the format regularly to keep it engaging (e.g., "Start, Stop, Continue," "4Ls," or "Mad, Sad, Glad").
   • Try different facilitation techniques to keep things fresh.

5. Celebrate wins and successes

   • Acknowledge the team’s achievements, even small ones, to build morale.
   • Celebrate positive outcomes before diving into challenges.

6. Include everyone’s perspective

   • Ensure all team members have an opportunity to speak.
   • Use techniques like round-robin or silent brainstorming to include quieter voices.

7. Identify root causes, not just symptoms

   • Focus on finding the underlying causes of issues instead of just addressing surface-level problems.
   • Use tools like the “5 Whys” to dig deeper into problems.

8. Encourage continuous improvement

   • Regularly reflect on how the retrospective process itself can improve.
   • Keep iterating on how retrospectives are run to ensure they remain effective.

9. Follow up on action items

   • Review the progress of previous action items at the start of each retro.
   • Hold the team accountable for following through on commitments.

10. Keep it positive and forward-focused

• Focus on constructive feedback and solutions rather than blame or negativity.
• Frame challenges as opportunities for improvement in the next sprint.

6. Backlog refinement: how to prepare effectively

🎯 Activity: Backlog makeover If our backlog could go to the spa, what would it look like afterward? Let’s discuss what a fully pampered, perfectly refined backlog should have (e.g., clear acceptance, a fresh coat of priority, etc.) Each person adds one ‘makeover’ tip to the list (e.g., “less fluff, more stuff,” or “no more 'TBD'—it’s 2025!”). 🔹 Group synthesis: Vote on one experiment you’ll add to your next refinement session.

Backlog Refinement Best Practices

Goal: Ensure the backlog is well-prepared for upcoming sprints with clear, actionable user stories.

1. Prepare in advance

   • Review user stories and requirements ahead of time.
   • Ensure stories are well-defined and include acceptance criteria.

2. Collaborate on story details

   • Work with the product owner to ensure all user stories have clear definitions and align with sprint goals.
   • Ask clarifying questions to ensure complete understanding.

3. Estimate user stories together

   • Use consistent estimation techniques (e.g., dev days).
   • Involve the entire team in estimating to get a broader perspective.

4. Prioritize based on value

   • Work with the product owner to prioritize user stories based on business value.
   • Focus on what delivers the most value first.

5. Break down large stories

   • Split complex stories (epics) into smaller, manageable tasks.
   • Ensure stories are small enough to be completed within a sprint.

6. Refine acceptance criteria

   • Ensure all stories have clear and specific acceptance criteria to guide development.
   • Test the stories against the criteria during refinement.

7. Avoid overloading the backlog

   • Keep the backlog focused on the next few sprints, avoiding too many items far in advance.
   • Reevaluate older items to see if they are still relevant.

8. Review dependencies and blockers

   • Identify any dependencies or potential blockers for each story.
   • Discuss and plan for how to address them in advance.

9. Ensure user stories are actionable

   • Make sure each story is clear enough for developers to begin work without further clarification.
   • Remove any ambiguity to avoid delays during the sprint.

10. Time-box the session

• Keep the session focused and within a set time limit to avoid long, inefficient discussions.
• Regularly time-box refinement to ensure you’re not spending too much time on backlog grooming.

Outcome: A well-refined backlog with clear, prioritized, and actionable user stories ready for the next sprint.

7. Wrap-Up & Key Takeaways (5 min)

🎯 Goal: Ensure action beyond the session.

🔹 Final Round: “What’s one insight or best practice you’ll take from today’s discussion?”

• Everyone shares one actionable takeaway.
• Wrap up by summarizing top learnings and next steps.

Why This Works:

✅ Experience-Driven: PMs learn from real stories instead of theoretical best practices.
✅ Highly Interactive: Keeps engagement high through discussions and activities.
✅ Action-Oriented: Ensures takeaways can be implemented immediately.

Would you like any additional activities or refinements?