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.
Dan Radigan
Agile has had a huge impact on me both professionally and personally as I've learned the best experiences are agile, both in code and in life. You'll often find me at the intersection of technology, photography, and motorcycling.
