In previous posts, we’ve talked about Making Sense’s approach in every part of the development phase of a software product. During a project using agile management methods, we hold periodic sprint reviews. These provide us with useful information for establishing future objectives.

How does it work?

Scrum is an iterative methodology that has, at its core, what’s called ‘sprint’. We basically dive into the work in timeboxed sprints. Before each sprint starts, we plan and commit to an objective, and deliverables are based on what the team believes can be accomplished within that particular Sprint.

When the deadline date and time comes, the Sprint is closed, no matter what the status of the tasks and stories might be.

This type of “team-introspection” is an important exercise, since it provides us with information about how the team performed, a review of what was achieved or not, and an understanding of what caused the results we achieved, whether they were positive or negative. Thus, we are able to make adjustments or any required changes. In this way, the team is continuously improving in efficiency, in its ability to deliver, and in its predictability.

This is mainly done during what we call the Sprint Review process, which is held at the end of the Sprints. It is comprised of the following 3 main activities:

• Demo
• Retrospective
• Backlog Grooming

As part of closure on the whole Sprint process, we update our Scrum board. This often entails running reports and updating our team’s average velocity. This, in turn, is used as a measurement of how much the team will be able to achieve on subsequent Sprint Plannings.

For example, let’s say a team’s average velocity is 40 Story Points. For the next Sprint planning, we’d use that as a benchmark, and consider adding Stories and Tasks that add up to about 40 Story Points.

Demo

The objective of the Demo meeting is to show the progress of the project to the product owner so he can review and provide feedback. It’s a crucial meeting since it allows the team to continue working with the most relevant stories at each stage and with the right definitions and directions.

This is one of the major advantages of working iteratively and incrementally. Why? Because the Product Owner is able to get involved in the project from the early stages and make the necessary adjustments during the development until the final version of the software product is achieved for release.

The most important asset to show is, of course, the working product. We should also include any asset or deliverables that require feedback, such as UX mockups, animated transitions, architecture definitions, technical designs and new functional definitions.

In order to add more value to this review, we could also include a presentation where we detail the following:

• the stories that were developed
• the story points that were covered
• the new average velocity
• any important meetings held
• changes in the team
• supporting material such as screenshots and videos

A good practice is to record these meetings for future references. We also like to maintain a document for feedback where the Business Analyst, Tech Lead and/or Designer takes notes. Then later, those notes can be translated into new stories or improvements.

This Demo meeting is ideally done before the next Sprint Planning.

Retrospective

This is a meeting where we all review how we did and what we need to do to improve or remove any impediments.

All team members are encouraged to participate and to provide their feedback. The typical tool to facilitate this meeting is to have a spreadsheet or board with three main columns:

• What went well
• What went wrong
• Action Plan or Action Items

We first focus on mentioning everything that went well. There are several objectives here. For starters, it provides the opportunity for us to recognize good work from team members, or help that someone might have given, or extra effort, collaboration and communication between teams and any fact that contributes to making the team perform better. It may be also a reminder of why we follow certain rules, what part of the process is really helping, etc., all of which is good to document.

Then we focus on everything that went wrong, or that could be improved. For example, we discuss situations that caused issues or made the job more difficult. The right mindset is to explain the facts and why it was an issue or problem, and not to try to justify or hide them.

The second part of the meeting is to focus on what we can do to solve those issues. If there are a lot of them, we first combine the ones that are similar or that have the same root cause. Then, each member votes on the ones he or she considers the most important to solve. Each may have 3 votes. At the end, we obtain a list of ranked issues on which we’d like to focus.

We all develop and offer our ideas on how we can solve or improve each item and we all agree on specific action points. We also add who is responsible for coordinating or implementing each action.

In the next Retrospective meeting, a good practice would be to review whether all the action plans were accomplished and if not, add them to the current Retrospective or explain why they may not be relevant any more.

These meetings are typically held a couple of days after the Sprint is closed, so that it doesn’t interfere with peaks of work that may happen around that time. There are cases in which a Sprint may not last more than a week and/or the team already went through many Retrospectives and there are not many issues to solve, so the team can agree to decrease the frequency.

Backlog Grooming

So, up to here we’ve covered 2 phases: Demo and Retrospective. Backlog Grooming, the last phase of our Sprint Review, can be held during a meeting or as an ongoing task. The participation of the Project Manager or Scrum Master, Product Owner and Business Analyst, is important. The Technical Lead can participate if required.

During Sprints and specially after each demo, stories and improvements may have been added. This activity is about reviewing the backlog in a regular basis, making sure all the relevant stories are captured and with the right priority and that the next stories the team will be developing have the right information, conveyed in a complete and clear way.

It is ideal to have the Tech Lead give an estimation of all the Story Points building up in the backlog. Such estimations may also be reviewed as part of this activity. Having an estimation of the backlog allows team members to build timelines, to define target delivery dates for features or releases and prioritize more efficiently based on the progress and remaining time. It also facilitates redefining scope or making decisions such as whether to change the team size or the target dates.
–
In my personal opinion, Sprint Review activities are the most interesting and necessary part of the process. Demos could be really fun and charming, especially when the client or product owner loves what they see and the team feels proud of their achievements.

We are all witnesses to something new that is taking form and that may be very interesting to the users or to the world.

Doing retrospectives where the client is always invited, allows us to transmit even more transparency about what we are all doing and how we can all do better work. I also enjoy becoming aware of how the list of issues to solve becomes smaller as we move forward.

Every project has its own characteristics and every team is different, and even in the same project it may change during time. The change is constant, so doing frequent reviews is what allows us to keep improving and learning over time, as professionals and team mates.