Goals of Scrum Meetings
Pritesh Jagani
![Pritesh Jagani]()
Pritesh Jagani
Sr. Product Manager | I help international students to Study Abroad (USA), land their dream job, and navigate their immigration journey
Just wrote a best practices for my organizations, thought I would share here and get feedback on what everyone else thinks.
Sprint Planning -
Goals of this meeting -
- Ask for PTO/Capacity/Other competing projects in the beginning of sprint planning or before committing the stories for the sprint.
- The whole team needs to agree on the sprint commitment.
- Sprint Commitment - It is the work commitment for the sprint done by team and not stakeholders.
- Nothing should be added to sprint once its started - unless you have very strong compelling reasons.
- Before commitment - consider the time on other projects, consider the code reviews, other logistics.
- Sprint Goal - Goal should not be just to complete the Dev work (Unless specified by Stakeholders) but to move the story to "Done".
- Defining Done - It varies from project/team to project/team. For eg - for one team it could be get the dev work done - QA and Doc can catch up later. (We are not really doing Agile/Scrum)
- Recommended - Complete Coding, code reviews, unit test, testing/QA, documentation. (this should be define by team, stakeholders, product owner)
Sprint Reviews -
Goals of this meeting -
- Get feedback from stakeholders.
- Review the status of sprint/ What got done and what's left
- Review/Demo the stories completed and ask the stakeholders if they think the stories are done.
Backlog Grooming -
Goals of this meeting -
- Groom the user stories in the backlog and prioritize them for next sprint.
- Add the acceptance criteria with the help of team.
- Estimating the stories - which gives you a head start for your sprint planning.
Daily Scrum
Goals of this meeting -
- Scrum master should only ask these questions - What did you work on? What are you working on? Are there any blockers.
- If the team is talking about technical details - guide them that they can discuss after the meeting.
- If the team starts to change scope then schedule a separate offline meeting to discuss that with product owner.
- Biggest takeaway - If the team is blocked then help them resolve the blocker.
Retrospective
Goals of this meeting -
- What went well? and what did not go well(Lessons learned)?
- Did the estimation work well? No? - What would you like to change? what did you learn from the sprint?
- Did you have hard time communicating with team? - Yes - How would you like to change?
- Did Daily scrums convey the team progress well? Were your blockers resolved quickly?
- Would you like to add new process/change any process.
Please comment and let me know what you think and if you have more points - I'd love to learn from you!
Manager of Project Management at Morningstar
3 年Pritesh Jagani, A-CSM Daily Scrum is for Developers to inspect the progress made towards Sprint goal and make changes in the plan based on that. Scrum Master should be a silent listener in a Daily Scrum meeting. He should ensure that Developers should have this meeting everyday and it should not take more than 15 meetings. I don't think SM should ask those 3 questions in the meeting everyday.
Product Manager l Reforge member l Former Engineer ??
4 年Hello Yudi, Nice article. i just have one doubt on daily scrum meeting "If the team is talking about technical details - guide them that they can discuss after the meeting" well they can discuss with whom after the meeting? Is scrum master needs to help on technical issues?
Senior Software Engineer at Mixpanel
7 年Great article, lots of solid information and best practices. This is pretty similar to how we operate at my organization. Having manageable, well-defined work that makes sense from all perspectives (developer, product owner, stakeholder) is the most essential requirement for good progress. A couple of my own opinions: 1. We tend to view the sprint commitment as more of a sprint forecast. Software development is never 100% predictable - sometimes a story that seems simple will end up being complicated once you dive into it, and vice versa. As you cycle through more and more sprints your team will get to know each other and their work better and become more accurate in their sprint forecasting. 2. Make sure the rest of the organization (operations, security, even marketing) is involved in the process. Obviously you don't want a marketing person to be part of the daily scrum, but the work that developers do will eventually make its way to the other parts of the organization. Give them read access to the story board and let them know they're welcome during sprint planning and retro. They might have some insights from their perspective of the company that are valuable during development.