Agile Team Meetings and Ceremonies
By: David Short
Tags: Sprint Planning, Agile, Scrum, Agile Methodology

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