Scrum is intended to be an iterative and incremental approach to improving the software development process. There are 3 key scrum ceremonies designed to help facilitate improvements to your process:
- The “Daily Stand-up”
- Sprint Planning
- Sprint Retrospective
We first presented these ideas to a room full of Constant Contact developers who engage in Scrum practices every day. At the time, we didn’t dive too deep into the purpose of the ceremonies, instead focusing mainly on the best practices. In this post I dive deeper into the 3 ceremonies, discussing their intended purpose and an expanded list of best practices.
The “Daily Standup”
In some circles the Daily Standup is referred to as the “Daily Scrum”.
Time limit and focus
In either case, for a team of 10, Standup should only last 15 minutes.
Yes, I said 15 minutes.
The purpose of the Daily Standup is to give every member of the team an opportunity to provide an update on their status. For the ceremony to work, it helps to have everyone standing up. Participants need to stay focused on their immediate status by reporting on:
- what they did yesterday
- what they intend on doing today
- any impediments (or blockers).
In order to effect this best practice when we conduct the daily standup, we should go around the room focusing on each participant, and not focusing on the board. The board is there to support status reports, but not be the focus. Every person should have a status, but not every story requires an update.
Who attends
There’s some debate as to who should attend standup. The general rule is that the Scrum Master and all members of the development team should attend. What about the Product Owner, though? My research led to a bunch of conflicting viewpoints on this. There’s even a funny story about The Chicken and the Pig which takes aim at the question. Personally, I like to hear our PO’s status since this is usually one of the few times I get a glimpse into the discussions going on outside of the engineering bubble.
Audience
Finally, we provide our status to the entire team, not to the Scrum Master, Managers or Team Leads. This helps to keep the team on the same page and fosters collaboration amongst the team, which is crucial to meeting sprint goals. To that end, it helps to leverage technology when you have remote team members, or folks working from home, in order to provide a seamless experience for everyone involved.
Best Practices
- Standups should be conducted with participants standing.
- Go around the room – not the board. Every person should have a status, but not every story requires an update.
- Address the team, not your Scrum Master, Managers or Team Leads.
- Focus on what you did yesterday, what you intend on doing today, and if you have any impediments.
- If it doesn’t fit within the above format, take the discussion off-line – and with only the relevant team members.
Sprint Planning
The purpose of Sprint Planning is for the team to appropriately commit to sprint work. A good sprint plan has enough work to keep the team busy, but not so much work that the team has items left over. Getting close to the goal on either end means you’re doing it right. Still, it’s possible to find the sweet spot.
Our team once went for such a large stretch of time where we ended every sprint exactly as planned, that we started to refer to ourselves pompously as the “Dynasty”. It was a great time!
How do you find the sweet spot?
Pointing stories for your sprint isn’t an exact science, so, initially, it’s often difficult to find your team’s sweet spot. For our team, the start of the sprint marks the beginning of a team-wide mission to complete everything we committed to. So when planning, we take into account metrics from previous sprints including average points completed, and velocity. We also take into account team capacity, including vacations, holidays, and other commitments team members have.
Different teams have different philosophies around how perfect a sprint plan needs to be. It’s been my experience that finding the sweet spot and completing sprints consistently, over a long stretch of time, can boost the team’s confidence and foster trust amongst the team members. It’s also a huge benefit to the business, as they will be able to more accurately plan ahead.
Best Practices
- Review the last sprint to align for the next sprint.
- Take into account vacations, holidays, trainings and other commitments that would impact individuals ability to contribute to the sprint.
- Make it your team’s mission to complete every story in the sprint.
- Use a velocity spreadsheet which can be used to project how many points the team can complete. See screenshot below.
- Failure is not an option! *I’m kidding* 😉
Sprint Retrospective
The Sprint Retrospective or “Retro” is a ceremony that helps uncover actions you can take to iteratively improve the software development process. While the purpose of the Retro is defined, the process is flexible. What works best here will be dependent on your team. The key is to try things that lead to specific actions that the team can take to improve the process.
Our team has tried games, drawing exercises, and sticky notes on the wall. One of the simplest methods is the “What went well”, “What can be improved”, “1 Word” category exercise.
With this, members of the team place cards on the wall containing items for each category. They then discuss the positives of the Sprint, dive into areas where things can be improved, finally stopping at 1 word to reminisce about the Sprint.
Pro tip: Use hashtags, camelCase, AND/OR dashes to get around the 1 word rule 😛
After doing a quick lap around the items on the wall, they circle back to the “What can be improved” category to dot-vote on the ones they want to discuss the most. This is an iterative process so it’s not necessary to tackle every issue at once. Dot-voting will lead to the top 2-3 retro items that folks want to talk about.
Regardless of how you get there, the actions to take should be the outcome of each of your retros. Each retro should result in 2 or 3 steps which will help improve the process. It’s also worth noting that actions can be things to try during your next Sprint to see how they improve (or don’t improve) your process. i.e. you don’t need to feel like you’re committing to doing something forever.
Best Practices
- Find what works for your team, try different things like games, drawing exercises, and cards on the wall.
- Dot-vote on retro items to identify the issues that the team wants to discuss the most.
- Keep track of the actions that the team has committed to taking and remind the team throughout the Sprint (even if it’s only on a sticky note).
- Get more ideas by asking about attending other team’s ceremonies. This will bring Insight into how other teams work and generate lots of new Ideas on how to improve your process.
Disclaimer: make sure the other team is comfortable speaking with a new person in the room.
The basic premise of this post is that each ceremony has a purpose and an intended outcome. By understanding its purpose you can maximize the outcome of each ceremony, allowing you to continuously improve your team’s software development process.
In the next post from our Scrum Hacks series I’ll share some tips on how you can completely hack your team’s Scrum.
See you then!
Coach’s Corner
(Michael Nir)
Here are some more thoughts on the various scrum events (you can call them scrum ceremonies if you want, that’s how they’ve been framed, however it is somewhat pretentious by the scrum gods to use the term ceremony – basically they are just meetings – by the way – for better results: name the meetings that you want to succeed: workshop – it has better results…but I am going on a tangent…)
Standup – I’ve noticed many times that using a physical board, JIRA and other tools, teams create swimlanes based on the members of the team – this results in a standup resembling a project status meeting – and team members refer to the stories as: “my story this, my story that”; instead opt for swimlanes based on the stories that the teams pulled into the sprint; this leads to better team collaboration and more swarming around stories to drive story completion.
Retrospective – here’s one of those tricks of the trade. As a Gestalt therapist working with teams, I’ve long learned that to increase team collaboration always start with small team collaboration – how small? – work in pairs.
The first step to an awesome retrospective is have team members pair up – possibly with another that they haven’t worked with much in the last sprint – and discuss their take aways for the retro (to keep, to stop, to start – is a retro approach that Mike Cohn uses and that I like). Working in pairs for 15 minutes increases rapport, builds solid foundations and gets all participating.
Sprint Planning – teams tend to forget the two following important deliverables during sprint planning – tasking and sprint goal (from the Scrum Guide):
How will the chosen work get done? Create tasks!
The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint.
Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.
The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint. By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
Sprint Goal
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.
As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.
Leave a Comment