Getting Started With Sprint Reviews

Tags: Agile, Project Management, Scrum, Software Development

As most of you probably know, Scrum is process for a agile product development based on principles stated in Agile Manifesto more that 10 years ago. Process consist of short iterations named sprints that usually last 1-3 weeks. On the end of each sprint team presents result of their work to the peers, users, customers and stakeholders.

Sprint review meetings facilitates three important aspects in product development

1. Fast feedbacks

Sprint review serves as a Poka-Yoke mechanism and enables to detect design flaws and hidden requirements early in the process, long before we ship final version to the market. Once the problems are known it is easier to reprioritize work items to meet new requirements.

2. Thrust  and co-operational relations

Sprint reviews promote frequent communication between users, customers and the team. For customers, more often than not, it is refreshing to see progress on the regular basis. On the other side, team gets opportunity to show what is done and to verify if product really matches user needs. It builds co-operational relation between parties.

3. Learning

Each party learns how to play it’s role in the product development process. Users will quickly learn how to specify requirements and developers will learn more about business rules and process.

Who should participate?

Well, everyone is invited. Developers are there to present what is done. Management, trainers, domain experts, end users, peer developers are there to learn what is done and to give input on new features planned for next sprint. There are some rules that we must adhere:

1. Sprint meeting is held on regular basis each week, or each two weeks in the same time

2. Sprint meeting is time-box meeting  (1 or 1,5 hours), with max 2 hours for preparation

3. No PowerPoint slides, just deliverables (working code, training material) that has value for customers.

4. Developers should present only those features that are done, with no known outstanding work. It means that they are implemented, tested, integrated with the rest of the code and basically ready to be shipped.

5. Features that are not ready for shipment should not be presented in any way during this meeting

6. It is informal meeting

7. Someone should take notes and write down all suggestions for improvements during the meeting

What we want to archive?

1. Presentations will help the team to come up and maintain common done criteria for the system you are building.

2. Right now we really miss fast feedbacks. Time span from initial requirement to build a feature to the actual rollout is at least couple of months. We have to do what we can to make it less than six weeks.

3. This meeting will enable the team to discover and resolve flaws and impediments in work process quickly.

4. It will make obvious what is done and what is not

5. It’s a great way to build trust between participants on the project and stakeholders

6. Presenting results of work usually boosts team morale. It’s always nice to share results with peers and users

Inspect and Adapt

First couple of meeting will uncover a lot of problems. Undefined done criteria, foggy requirements, over commitment and complex code base are just some of them. It is essential to encourage everyone to talk about problems openly. Inspect your work process and adapt it to address observed flaws and impediments on regular basis, after each and every sprint review meeting.

Next steps

1. Schedule first Sprint Review, now!

2. Meet with team members and share your experience and expectations from the first Sprint Review (30 minutes meeting)

3. Define initial done criteria for software (30 minutes meeting)

What do you think?

What is your experience with Sprint Reviews? What would you suggest to someone who is just about to take part in the first Sprint Review?

Leave your comment