Setting up a cadence on your agile team

I’d like to share with you a common cadence that we are using on agile teams that I coach, and also on many of AgilityFeat’s development teams with our clients. For an agile team to get into a solid rhythm of work, they need to have a set cadence of sprints. This means that demos are always done on the same day (regardless of level of completion), sprints always end on the same day, planning is always done on the same day, etc. While there are obvious exceptions around holidays, it’s important that you stick to the same size sprint as much as possible. Without that set cadence, your team will lose rhythm and focus, and metrics like story point Velocity will be meaningless.

A Typical 2-week cadence

On teams I am coaching right now, we are setting a regular cadence of these meetings:

• Standups – daily of course
• Prioritization meetings
• 3 Amigos meetings (a concept I learned from Lithespeed and George Dinwiddie)
• Estimation meetings
• Planning meetings
• Demo and retrospective on the same day

For teams that follow a two week sprint, here is an example of what your cadence may look like on a calendar.

Notice that this cadence is ongoing across sprints.  The planning meetings for a given sprint are spread out over the previous two weeks, so that in true agile fashion, you are regularly doing small chunks of planning just before the actual work is to be done.

Setting up a cadence like this means that your actual sprint planning meetings will be pretty short, because most of the hard work was done in prior 3 Amigos and estimation meetings.  This makes for less stress on the team because there is time to correct any deficiencies or gaps found during the planning process.

It’s also less stressful for the Product Owner, who is assumed to be drafting the stories in this model, because they know exactly when they need to have the stories done by, they have time to do it in small chunks, and there is time built into the schedule for them to meet with stakeholders and confirm priorities.  Instead of having a half day marathon planning session filled with questions, your planning session will often be 30 minutes or less because you already hammered out the details of each story and the team has already agreed the story meets their “Definition of Ready” for development.

Here’s a break down of each meeting:

Prioritization Meeting

—Purpose:  Review the backlog, and adjust the priorities of upcoming stories as necessary.  Product Owner can make projections of when stories will be worked on based on historical velocity, but they cannot commit the team.

—Look out for:  Any fixed constraints or new issues from stakeholders may require changing priorities

—

Outcomes:  Product Owner knows what stories to prepare for the 3 Amigos meeting

3 Amigos Meeting

Purpose:  Review the upcoming stories for the next sprint.  This is a chance for the team to verify that the “Definition of Ready” criteria are all met and the team has a shared understanding of the story to be developed.

—Look out for:  Missing Acceptance Criteria, dependencies on external resources or architects, edge cases that need to be considered.

—Outcomes:  The team agrees that this story can be estimated and can be considered for the next sprint’s planning session.

Estimation Meeting

—Purpose:  Go through all the candidate stories for the next sprint.  These stories should have already been approved in a 3 Amigos meeting, or adjustments made based on feedback from that meeting.  Stories are estimated by the full team using story points.

—Look out for:  Major team disagreements on what a story means.  If stories are too big to be comfortably completed in the sprint, they should be broken up.

—Outcomes:  1-2 Sprint’s worth of User Stories are ready for planning.

Planning Meeting

—Purpose:  The hard work has already been done.  Now the team is just going to compare the list of prioritized, estimated stories to historical velocity and decide how many to commit to in this sprint.

—Look out for:  It’s ok for the Product Owner to add stories at the last minute on occasion, just prioritize and estimate them quickly at the beginning of the meeting prior to the planning.

—Outcomes:  A completed Sprint that the team is comfortable committing to and tackles the Product Owner’s highest priorities.

Too many meetings? Maybe!

This may look like a lot of meetings, and depending on your team, it may be too many.  Remember, agile methods are not meant to be overly prescriptive.  Do what works best for you, but this is a common pattern I see, especially at large companies where there are lots of stakeholders to coordinate with before a sprint can be planned.

Agile teams that are particularly small or have product owners with complete authority may not need this.  Other agile teams may just be very mature or working on a system that they understand completely, and they don’t need the extra hoop of 3 Amigos or prioritization meetings.  If your team is already doing all the planning in 2 hours or less and still maintaining high quality, then this example cadence may be too much overhead for you to incur.

But if your scrum team is taking a half day or more to plan a sprint, or there is lots of argument during the sprints about what user stories actually meant, then this type of cadence may work well for you.  Try it out for a couple of sprints and see – you can always change it later!