Sprint Reviews

Sprint reviews are not retrospectives. A sprint review is about demonstrating the hard work of the entire team: designers, developers, and the product owner. At Atlassian we like to keep our sprint reviews casual. Team members gather around a desk for informal demos and describe the work they’ve done for that iteration. It’s a time to ask questions, try new features, and give feedback. Sharing in success is an important part of building an agile team.

Let’s first review why the team’s definition of ‘done’ is so important to this agile ceremony.

As a regular user of Jira, there’s nothing more satisfying to me than moving a task from ‘code review’ to ‘done.’ That swoosh of an agile card represents completed work we set out to accomplish as a team. Done and done!

Crossing the finish line and completing work requires good planning, a clear definition of ‘done,’ and focused execution. Most of this happens during sprint planning, but to have a successful sprint review and sprint, teams need to do a little more than plan. They need to develop a clear culture of how to deliver work as well as what it means to be ‘done.’

Effective teams bring clear processes and development culture to each and every work item. Use these questions to assess your process, and make sure it’s working optimally for your team:

• Are stories well-defined by the product owner, designer, and the engineering team before implementation?
• Does everyone understand and live the team’s engineering values and culture?
• Are there clear definitions and requirements around code review, automated testing, and continuous integration to encourage sustainable, agile development?
• After the team completes a story, are there many bugs that surface? In other words, does ‘done’ really mean ‘done?’

The team’s culture around quality and completion should rise above every user story, engineering work item, and bug. This culture is reflective of how the team approaches and delivers software.

​

A clear definition of ‘done’ helps teams focus on the end goal for each work item. When the product owner adds work to the team’s backlog, defining the acceptance criteria is a key part of his or her process. What does it mean for a user story to be complete? At Atlassian, the Jira team tracks acceptance criteria and testing notes right in line with the rest of the user story inside of Jira. That way, the entire team has a clear view of success on every issue. What are acceptance criteria and testing notes?

• Acceptance criteria: metrics the product owner uses to confirm the story has been implemented to his or her satisfaction.
• Testing notes: short, focused guidance from the quality assistance team that enables the development engineer to write better feature code and automated tests.

Having well-defined issues during implementation allows everyone to be successful. With Jira, it’s easy to add fields in line. As an administrator, just click the ‘admin’ button on the issue.

At Atlassian, one of our core values is to “play, as a team.” Sprint reviews are a great time to celebrate the team and everyone’s accomplishments during an iteration. We typically host them on Friday afternoons, while everyone in the office winds down before the weekend. Sprint reviews are not synonymous with retrospectives, so make sure to host the sprint review after an iteration, but before your retrospective. External participants are always welcome to join, but the meeting usually consists of the product owner, the full development team, and the scrum master. As a best practice, we recommend spending 30 minutes to an hour for each iteration in the meeting.

We love sprint reviews because they protect the health and morale of the team. Sprint reviews are all about team building. The review isn’t adversarial, it’s not an exam—it’s a collaborative event across the team in which people demo their work, field questions, and get feedback.

If a sprint review doesn’t become a positive activity across the team, it may be indicative of:

• The team taking on too much work and not completing it during an iteration
• The team struggling with existing technical debt
• Features not being developed sustainably to ensure new bugs are not introduced into the codebase
• The team’s development practices aren’t as tuned as they could be
• The product owner is changing priorities within an iteration, and the development team is sidelined by scope creep

Note: every team has a difficult iteration sometimes. Take the time to understand why an iteration changes in the team’s retrospective and create a plan to address issues in the next sprint.

Companies with distributed teams have special challenges around scaling agile ceremonies across geographies. Sprint reviews are no exception. The Jira team has members across the globe: Sydney, Gdańsk, Saigon, and San Francisco. Even though we’re distributed, sprint reviews are an important part of our team culture. Team members create informal videos and share them on a Confluence page for the entire team to see.

These informal videos keep everyone up-to-date on the progress of development despite time differences. Seeing a feature demo first-hand by the developer strengthens the team in two ways:

• Product Understanding: the entire team gets to hear the intention, rationale, and implementation of the feature. It broadens everyone’s understanding of the entire product.
• Team Building: videos create more personal connections across the team. Each of us gets to see who’s behind every aspect of a product. The bridges created by this practice makes us a tighter, more cohesive group despite geographies.

For teams that are new to sprint reviews, there’s a strong temptation to bleed sprint review into the retrospective. A sprint review is an independent ceremony from a sprint retrospective. Take the time to enjoy the fruit of your labors. Liberally celebrate accomplishments. Effective sprint reviews build up the morale and motivation of the team. This idea of celebration is so important to us on the Jira team, we’ve incorporated “go ahead, celebrate” into our vision statement for this very reason.