Table of Contents
Background
There are many other guides out there about Sprint Ceremonies. I am taking the time in this article to explain my perspective on the usefulness of each meeting and how to ensure that the time spent to coordinate on them is useful and not a distraction or a waste of time.
For each sprint ceremony, I've broken down into subsections:
- When to have the meetings and for how long
- How I have learned to effectively run the meeting
- Why each meeting is necessary
Daily Stand-up
Daily Stand-up: When
Every day blocked off for 30 minutes but could take as long as 10 minutes even on large development teams.
Daily Stand-up: How
The most effective stand-ups I've been a part of made use of an Excel spreadsheet to allow all team members to write their answers before the start of the actual meeting. In the spreadsheet, dedicate the first column to the list of team member names in the order they will present (I am used to alphabetical order by first name). Title the next 3 columns:
- What I did yesterday
- What I will do today
- Any blockers
Team members will fill out their rows either before or at the very start of the meeting time. Then, in order from top-to-bottom, members will recite their entries out loud. Any further discussion topics that don't belong in the previous rows will be marked at the bottom of the sheet as a "post-scrum".
Once every team member has recited their row and all post-scrums have been discussed, the meeting ends.
Daily Stand-up: Why
I personally enjoy the "what I did yesterday" and "what I will do today" entries as personal goals / checklists to work toward and to keep me focused. But as a team lead, the "blockers" column is the most important, followed by post-scrums. Nothing is more demoralizing than being blocked by a task needed to be performed by someone on the same team and waiting weeks at a time. A blocker that is a quick action item that is visibly written every day proves to be a solid reminder.
Stand-up also provides a dedicated venue as well for brief but constant team discussion. For teams with remote employees, there's a significant mental difference between reaching out for a Zoom call vs. leaning over into a coworker's desk to ask a question.
It's important to ensure that the stand-up meeting stays capped to 30 minutes and any further discussion is properly scheduled and scoped to the correct number of people. This isn't to avoid having long, team conversations but to instead ensure that the meeting itself does not subtly expand to too long.
As new team members acclimate to the company and its processes, it may happen that most stand-ups take place with no blockers or post-scrums to review. This is fine and good! Stand-ups should still be slotted to 30 minutes in the event that there is a larger discussion that needs to happen, even if you'll now experience regular 5-10 minute meetings.
Triage / Sizing Sessions
Triage / Sizing Sessions: When
Triage should be held at a regular cadence depending on how often new tickets come in. For some teams, this may need to be a dedicated block of time after every stand-up; for others, ideally once-a-week. I believe 30 minutes is enough, but adjust longer or shorter as needed based on intake.
Sizing Sessions are separately scheduled ad-hoc meetings when a larger development project is split out into smaller tickets. Because these Epics will typically entail much larger wholistic discussions, I recommend booking a full hour and ending early if deemed appropriate.
Triage / Sizing Sessions: How
Triage tickets are reviewed in order starting from oldest-to-newest. Sizing session tickets are reviewed in the appropriate order to work on them within the given project.
Everyone on the team will be participating in Scrum Poker as they review and size each ticket. I am partial to playscrummy.com as the tool to facilitate this.
For each ticket, each team member needs to mentally answer the following questions:
- Is the ticket appropriately categorized (i.e. correct labels and priority)?
- Are the outcomes for this ticket clearly understood?
- Are the outstanding questions required of this ticket small? For example, the outstanding questions are related to actual code implementation details ("What unit-tests do I write?") and not issues with what conceptually is being asked ("Why are we doing this change when only 1 person has asked for it? Have we checked with other stakeholders on what their thoughts on this change are?")
- Would I be able to address this ticket if it were assigned to me? If not, what other information do I need in the ticket to provide further clarity?
- Is the scope of this ticket appropriate? Are follow-up tickets needed in order to break out what is being requested into smaller steps?
In practice, whoever is leading the session will reveal the ticket, read the description aloud, and ask for general feedback. If there is feedback, the lead may document these questions as comments onto the ticket. If there is significant feedback, they may then move onto the next ticket without moving the current ticket out of the inbound queue. This means the ticket will be re-reviewed at the next Triage / Sizing Session.
If there is no feedback, the team then uses scrum poker to assign the number of story points to the task. There are a number of guides out there for what story points should correlate to; the important part is that the concept of story points remains consistent to the team. For me, the typical vibe for each number is as follows:
- 1: Very quick, almost asinine. For example:
- A typo is reported on a documentation page and needs to be changed.
- A configuration update is needed that involves toggling 4 buttons after following a procedure doc.
- 2: Small change. For example:
- A code change, like a quick bug fix, is needed that requires no test updates
- Boosting code coverage by adding more unit-tests without a functional code change
- Writing documentation
- A code change that would be big but is a copy-and-paste of existing code with smaller changes added onto it
- 3: Regular change. Majority of tickets fall into this bucket. For example:
- Code changes with both an update to the base code along with adding unit-tests
- 5: Large change. For example:
- Any change where the path-to-action is uncertain, like investigating a new library or new architectural strategy
- A code change that requires a refactor that touches a significant part of the codebase
- 8: Too big! Anything given this size typically means that the ticket needs to be re-conceptualized. What uncertainty is causing this to be too big? Are there clear "sections" of outcomes that would be best to split out?
- An exception would be if the work itself is appropriate to group together, i.e. performing a small configuration change against 50+ repositories. Keeping an 8-story-point ticket would be considered more user-friendly to update than 50 1-point tickets and maybe more accurate to the amount of work performed.
After all members have voted, reveal the results:
- If all numbers are the same (i.e. "3, 3, 3"), assign that number ("3") and move to the next ticket.
- If all numbers are within 1 deviation of each other (i.e. "3, 5, 3"), assign the highest number ("5") and move to the next ticket.
- If all numbers are 2+ deviations of each other (i.e. "2, 5, 3"), the members of the team who voted the lowest ("2") and highest ("5") need to be encouraged to discuss their reasoning. This means that there is a fundamental disagreement over the expectations of the ticket. Having this conversation now means that an incorrect assumption was successfully avoided in the future where it would be more difficult to course-correct. By the end of the discussion, members will re-vote to decide the final story point value and move to the next ticket.
Process repeats until all tickets are reviewed or the meeting time has reached its end.
Triage / Sizing Sessions: Why
Every ticket submitted to the team gets to be reviewed as a team. This enables knowledge sharing among team members and avoids having one person bear the burden of understanding and breaking down work. For larger teams or for teams with remote workers, this enables also having a shared understanding of what members of the team are working on.
The key needs for story points are two-fold:
- Enable discussion between team members in cases where team members understood the request in a ticket differently
- Better understand the speed ("velocity") of a software development team to best estimate project deadlines.
Having each ticket sized at the same time will also surface conversations that may have been skipped. For example, a team reviews a new ticket: verbally, everyone says they understand the contents of the ticket and what it set out to accomplish. However, after sizing the ticket, one of the team members scores it a 2 and another scores it an 8. That's a huge difference! Had the team not sized the ticket, there may have been unspoken confusions over what the actual request of the ticket contains. Keep in mind a delicate balance is needed for how long this session should take. I have seen sizing sessions going on for an extended period of time that result in all team members consistently choosing safe "3"s in the interest of wrapping up sooner without back-and-forth.
From the developers' perspectives, story points should not matter. They should not be used as a comparison metric between team members, and software development team leads should avoid setting up a display for points accomplished as a scoreboard. For other teams like those in IT, a scoreboard may be a fun challenge if the tasks are all very procedural. For software development, it's highly likely that 8 tickets that are each "1" story point will take a significantly shorter amount of time than 1 ticket with "8" story points. This may incentivize wanting to avoid larger, more difficult 5-8 point initiatives in favor of scooping up smaller tickets immediately as they come in, or the potential where manual processes that require smaller tickets to be created are pushed forward instead of seeking out automation.
Meanwhile, team leads should look at the end of each sprint to examine the number of story points accomplished and seek out a trend. This trending line - referred to as "velocity" - will provide a rough estimate for what a comfortable range of story points that can be taken on and completed for each sprint.
Backlog Grooming
Backlog Grooming: When
Once a week for an hour at a point in the week where there's a lull - i.e. afternoon on Fridays - set aside 30 minutes - 1 hour for going through the oldest tickets in your ticket backlog.
Backlog Grooming: How
Bookmark a query or filtered view of tasks that sorts all of them by age created. As a team, review tickets in the same manner as Triage / Sizing Sessions. For each ticket, answer the following questions:
- Is the request in the ticket still relevant? Is it outdated or a duplicate of a ticket? If a duplicate, decided as a team which of the two tickets to rely on as the primary ticket (could be this older one or the newer one, depending on how thorough and relevant the content is).
- Is the request still needed? If the ticket is to address an issue that popped up once two years ago, this request should be treated as stale and opened as a new ticket if it resurfaces.
- Is the ticket's original submitter still asking for this request? Reach back out to them to confirm if their request has changed in the time that the ticket has been sitting in the backlog or if there is a more urgent need that they would rather have addressed.
- Re-size the ticket as a group to update the value and confirm that the team as a whole have a consistent understanding of the original request.
- Re-prioritize the ticket if appropriate to take on in the near future.
The vibe of this meeting is chill and nostalgic. If the team has been around long enough, this may be a fun trip down memory lane to 3-year old tickets.
Backlog Grooming: Why
It's easy if left unchecked for a software development ticket backlog to build up. There's may nice-to-haves for improving processes but only a limited window for what tasks can actually be prioritized. This meeting enables a balance to be had: all team members should feel comfortable documenting tasks they would like to have accomplished for the betterment of the team and the company, but the team does not feel overwhelmed by having a giant never-ending backlog of tasks that may not be prioritized.
Sprint Retro
Sprint Retro: When
Sprint Retrospective and Sprint Planning go hand-in-hand. Every 2 weeks, schedule a 1-hour meeting with the first half as the sprint retro and the second half as the sprint planning (see Sprint Planning: When).
Sprint Retro: How
Prior to the meeting, set up a team document with the following 4 headings:
- 🎖️ Kudos - specific thanks to team members who stood out with their efforts over the past sprint
- 🟢 What went well?
- 🔴 What went wrong?
- 💡 Action Items
Set up a 5 minute timer for the group to go through and write answers to the first 3 questions, leaving "Action Items" untouched for now. An alternative as well is for the team lead to go through each question in order and ask for members to speak up, where the manager then transcribes the answers. I am still on the fence about either approach. I would recommend the "Kudos" answers be said out loud; it's more meaningful personally when I was a junior developer to hear a senior developer say that my efforts were appreciated.
After the timer - or if following the manager-lead approach - go through the answers to each column and encourage any follow-up discussions. The answers to questions 2 and 3 should not be specific towards any individual; we are a team, so discussions should ensure ways that the team can better work together to address any shortcomings. If frustrations are pointed towards a different team in the company, what are ways we can improve our own processes to better assist them? (i.e. developing specific procedures to assist with investigation issues on our end before handing off externally for others to troubleshoot).
While going through the discussion for questions 2 and 3, any follow-ups are now written down in the "Action Items" column. After the meeting, the individual Action Items should be delegated to team members to re-made as proper software development tickets. Some retrospectives may not result in Action Items if the result of the discussion was either that there was no glaring process improvement that needs to be made or an issue that was encountered has a low probability of resurfacing.
Sprint Retro: Why
Software is written and maintained by people, so encouraging self-reflection is a must to resolve both software development issues and people issues. Team members should not feel that the issues with the team are stuck in their ways. Everyone should feel comfortable also clearly expressing frustrations in a blameless manner. Individualize the gains and socialize the losses. Clear, open, and honest communication.
Sprint Planning
Sprint Planning: When
Sprint planning takes place right after Sprint retrospective or in the same day. Schedule a 30 minute to 1 hour block of time right after or later in the day, depending on how much preparation is needed before the meeting.
Sprint Planning: How
Look over the past several sprints to see a trend of the number of story points are being closed out. Use this metric ("velocity") as a guide for how many story points to add onto the workload. If there are outstanding tickets not completed from the prior sprint, take them into account when setting up new work to take on. Communicate with stakeholders about potential delays in timing if those outstanding tickets will impact the original estimated timeline for the initiative.
As a team lead, look over the delegated story points just to get a sense for each member's workload and not as a comparison. If someone has a noticeable carryover from sprint-to-sprint not being accomplished, see if some of their tickets can be delegated to others (or in your regular 1-on-1, bring up with them to invite the discussion).
Ideally, for a given team of people, one member can be assigned to an "Operations" ticket queue for one-off requests, short repeated manual procedures, and monitoring application health and logs. The remaining members of the team would be assigned to larger project initiatives with clear estimated deadlines split out.
Sprint Planning: Why
Once a team is a well-oiled machine, Sprint Planning becomes a manner of communicating a timeline for completing a project with stakeholders with proper scheduling well in advance. A new project request comes in from a key stakeholder; how does this request compare to other priorities in the business? After breaking the project down to its individual steps in a sizing session, the cumulative story points compared to the team's velocity will inform us how many sprints to dedicate to accomplishing the work.
The end result is a clear queue of work and estimates. The team is happy because deadlines are not a matter of setting everything to as-soon-as-possible and should be comfortable to accomplish and push for (avoiding crunch, where possible and where the company does not enable crunch-conditions). Stakeholders are happy because they have a clear estimate for when they will be unblocked or can expect work to be delivered without it being lost to a void of uncertainty.
Top comments (0)