Code review in sprint

What is a Sprint Review?

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

As a regular user of Ravetree,theres 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 developa 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 its 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 teams engineeringvalues and culture?
• Are there clear definitions and requirements around code review, automated testing, and continuous integrationto 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 teams 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.

Defining done on each work item

A clear definition of done helps teams focus on the end goal for each work item.When the product owner adds work to the teams 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 Ravetree, the team tracks acceptance criteria and testing notes right in line with the rest of the user story inside of Ravetree. 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 allowseveryone to be successful. With Ravetree, its easy to add fields in line. As an administrator, just click the admin button on the issue.

Step 2: celebrate the team

At Ravetree, one of our core values is to play, as a team. Sprint reviews are a great time to celebrate the team and everyones 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 eachiteration 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 isnt adversarial, its not an examits a collaborative event across the team in which people demo their work, field questions, and get feedback.

If a sprint review doesnt 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 ensurenew bugs are not introduced into the codebase
• The teams development practices arent 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 theteams retrospectiveand create a plan to address issues in the next sprint.

Step 3: reach across geographies

Companies with distributed teams have special challenges around scaling agile ceremonies across geographies. Sprint reviews are no exception. Ravetree has team has members across the globe: Raleigh, San Francisco, Kiev, and Malta. Even though were distributed, sprint reviews are an important part of our team culture. Team members create informal videos and share them on the team's File 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 everyones understanding of the entire product.
• Team Building: videos create more personal connections across the team. Each of us gets to see whos 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, theres 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 Ravetree team, weve incorporated go ahead, celebrate into our vision statement for this very reason.