No matter where you fall on the agile scale from newbie to nimble, mastering the basics helps you and your team make awesome software. So in the light of the new year and bettering oneself, we propose three resolutions for your team – each one focused on an agile ceremony.
Keep reading to find out which agile ceremonies we think are most important. Plus, I’ll show you how to use tools like Jira Software to make agile ceremonies work for your team.
#1: Get serious about backlog grooming
At its core, sprint planning is about determining which work to commit to for the next iteration. But before sprint planning, a certain level of prep work is needed (usually referred to as “backlog grooming”). We’ve found that this makes the full-team sprint planning meeting more efficient.
During backlog grooming, the product manager and development manager prioritize new items in the backlog, and compare them with existing items to decide where everything ranks overall. They also review and flesh out user stories so the team has enough information to estimate and execute. But what if they aren’t able to add enough detail to a user story during the backlog grooming session? Teams at Atlassian take that as a red flag signaling that it needs to be moved down in the queue while the product manager clarifies the work needed to be done.
Once this “homework” is done, the whole team can get together for the actual sprint planning. As a group – and that is key – the team estimates the effort involved for each item in the backlog and moves issues into the sprint backlog. Without backlog grooming, this exercise (which should only take about an hour) can take 2-3 hours. Hours that could be spent doing development work.
Pro tip: It’s important that the team feels confident about the sprint forecast. At Atlassian, we get a verbal agreement from everyone in the room about what they’re committing to.
To present the sprint forecast we recommend you use the sprint footer in your backlog to calculate the total points for the sprint, and compare that with your typical velocity. This is a great way to use numbers to ensure that everyone understands the level of commitment.
#2: Make stand-ups work for your team (not the other way around)
If you played the word association game with agile, “stand-up” would probably be on the tip of your tongue. But, ironically, stand-ups are often misunderstood.
If you meet with your team on a daily basis, but don’t work in an iterative way, then you aren’t agile – you’ve just added another meeting to your calendar.
That said, stand-ups are a great gateway to agile. They inform everyone of what’s going on across the team in just a few minutes, and these quick updates can help any team work in a more iterative way.
If you aren’t practicing stand-ups yet, start with a 15-minute meeting (daily, three times a week, maybe just weekly) where each team member answers the following questions:
- What did I complete yesterday?
- What will I work on today?
- Am I blocked by anything?
These questions highlight progress or lack thereof. Notice how that first question uses the word “complete” – not just “worked on”. There’s a certain level of accountability when you have to report what work you completed the day or week before. No one wants to be the person lagging behind and not getting things done.
If your team is doing stand-ups, resolve to walk into them knowing what you are going to say so the meeting stays short and the energy stays up (especially if you opt for an early morning stand-up). A good trick we use a lot at Atlassian is to take advantage of Jira Software’s quick filters like “only my issues” and “recently updated”. When you use these two filters together, they show issues assigned to you that have been updated in the last day, and are perfect cheat sheet for your stand-up.
Another thing we’ve found at Atlassian, is that no two teams use the same format for stand-up – which is fine, because each team needs to figure out what works best for them. This may mean that a distributed team holds two video conferences a week, while a co-located team meets at 9:00 on the dot every morning. So take stock of your stand-ups’ format and timing, and see if an adjustment or two is in order.
Pro tip: To keep a stand-up on track, some teams use timers – each person gets X minutes – while others toss a ball to the next speaker to make sure that everyone is paying attention, while a distributed team would benefit most from video conferencing or group chat like Hipchat (which even has its own stand-up bot). Your team is unique, so your stand-up should be too.
#3: Look back to move forward
When a sprint ends there is one more agile ceremony before the next iteration starts: the retrospective. It’s tempting to push retrospectives aside in the name of getting on with the next sprint. But in the long run, they’re well worth the time.
Like stand-ups, retrospectives can be misunderstood. They aren’t a time for people to sit around and complain; they’re a time to dig into what’s working and what’s not working, and to develop an action plan for the upcoming sprint. It’s all about continuous improvement: only by looking back at the work just completed (or not completed) can the team learn and make the next sprint better.
Also like stand-ups, no two retrospectives are the same, but having structure does help. Try bringing in a facilitator from outside the teams, as many Atlassian teams do. This lets everyone take part in answering these questions:
- What should the team start doing?
- What should the team stop doing?
- What should the team continue doing?
Teams at Atlassian use qualitative data from sprint reports, velocity charts, and burndown charts to help answer these questions. (Jira Software and other agile planning tools generate these automatically every time you close out a sprint.) But don’t stop there: it’s just as important to understand how the team felt about the sprint.
Try this exercise, for example: at the beginning of the retrospective, ask everyone to write down a number between one and ten – one meaning “horrible” and ten meaning “awesome” – representing how they felt the sprint went. Then find the average of all of these numbers. It’s the closest thing to checking a team’s pulse.
If you do this consistently, you’ll have qualitative data on the ebb and flow of a team’s morale. And you can correlate that to changes in how you work together (or with other teams) and understand yourselves even better.
Pro tip: Publish notes and decisions from the retrospective using Confluence or a similar tool. Most teams at Atlassian use the retrospective blueprint, which makes it easy to create a page with the right information and structure.
Agile ceremonies are about communication
These resolutions underscore one tenet from the agile manifesto in particular: “individuals and interactions over processes and tools.” Sprint planning, stand-ups, and retrospectives are all about how individuals interact with one another. You can use tools to support team collaboration and communication, but it has to start with the human element. Only when your team knows how to work together and talk to each other will you reap the benefits of agile development.