Agile Team Meetings and Ceremonies
This is a genericized version of a document I prepared with a prior engineering lead on a sprint team where I was the Product Manager. We were operating in two week sprints.
None of these notes or meetings should be considered required (although books will tell you otherwise), and some of it definitely isn’t needed for every team. The way we used these meetings is slightly different from what some of the typical Scrum / Agile methodologies will provide. We got to these changes based on confronting challenges within our team, but that doesn’t mean they’re how every team should operate.
All events are organized and run by the Scrum Master traditionally, but we didn’t have a dedicated Scrum Master, so the engineering lead acted in the capacity.
Daily Standup / Scrum
Held every working day
Length: maximum of 15 minutes
Not a status meeting
Everyone stands up in front of the sprint board
Team communicates blockers and dependencies, gets help
What did I do since we last talked? What am I going to do before we next talk? Am I blocked on anything?
If a deeper conversation needs to take place, acknowledge that and split it off with the necessary people after the standup
Attendees: all Engineers, PMs, QA, Design (we didn’t have embedded Designers, and went for over a year without QA, but the full sprint team whoever they are)
Can be conducted over slack if more than 2 team members not in person.
Discovery / Design
Held each week (twice per sprint)
Length: maximum 1 hour
High level discussion of long term projects (epics) and vision for the team
Refine stories in backlog, including high level estimates of epics
Discuss any big changes: new technical complexity identified, new requirements uncovered through user research
Split stories down from epics, refine tickets to 80%
Assign final owner to bring tickets to a level of detail sufficient for “Refinement” or “Estimation”
Attendees: PM, Engineering Lead, Senior Engineering Manager
Refinement
(optional meeting, we added this because we wanted engineers to feel comfortable pushing back or revealing uncertainty in estimating, before they would just give an estimate and more frequently be unable to deliver the ticket within the next sprint)
Held in second week of sprint
Length: maximum 1 hour
Refine tickets, including negotiating and updating criteria
Create criteria which can be tested, enabling the creation of a test plan
Split tickets into smaller chunks of deliverable value
Add estimates of the complexity to tickets
Identify dependencies across tickets (this needs to be complete before that can be done)
Build up multiple sprints worth of work that is ready for implementation
Attendees: all Engineers, PMs, QA, Design (the full team that’s in daily standup)
Estimation
Held in 2nd week of sprint the day after Refinement
Length: maximum 1 hour
As we estimate tickets, engineers volunteer to work on them in the next sprint
Anyone on the team can always say there’s not enough clarity on the requirements and defer estimation until those questions are answered
Attendees: all Engineers, PMs, QA, Design (the full team that’s in daily standup)
Sprint Planning
Held on the first day of each sprint
PM signs off on sprint ticket priority
Engineers prepare for the meeting by reviewing tickets they have committed to in Estimation, looking at code base, and creating a rough plan for technical approach, testing, etc.
Length: maximum 2 hours
Each engineer shares the tickets they’re planning to work on and the approach they’ll be taking
Other engineers poke holes / ask questions of the approach proposed
Additional refinement and estimation if needed
Team members personally commit tickets to the sprint goal based on their velocity during the past sprint and the total capacity of the team for the sprint given any vacation, holidays, other commitments that will offset time coding
Attendees: All engineers
Most teams have PMs in this meeting who presents the tickets for the sprint and answers questions. My team preferred to have a deep technical approach conversation where I wouldn’t be as valuable, so we compromised. As PM, I set the priority of the tickets in the backlog as we assigned owners during estimation. During planning, re-estimation could take place if new information changed expectations, and the lowest priority items could be dropped, or I would discuss the alternatives with the engineers before finalizing the items that made it into the sprint and setting it live
Sprint Retrospective
Held at the end of each sprint
Length: maximum 1 hour
Reflect on goal from prior retro: did we do what we said we would?
Answer the questions
How’d this sprint go for you?
What did we do well and want to keep doing?
What do we want to stop doing?
What do we want to start doing?
Pick one thing from the discussion to add as the goal for the following sprint (in addition to delivering the work committed)
Attendees: all Engineers, PMs, QA, Design (the full team that’s in daily standup)
Sprint Review / Demo
Held at the end of each sprint
Length: maximum 1 hour
One or more engineers demonstrates software they built in the past sprint
Celebrate our successes and show off what we’ve accomplished
Anyone can ask questions and make suggestions for enhancements
PM creates new tickets based off of the discussion where appropriate, or does additional research to validate questions raised
Attendees: PMs, all engineers, QA, Design, Internal stakeholders / customers. Open to anyone interested in what the team is doing.
While this goes against the “rules”, I believe this meeting can be held less frequently depending on the structure of the work. Very backend heavy teams may not have readily demonstrable code at the end of each sprint.