How Spint Reviews help other teams

September 18, 2015

Are Sprint Reviews only for inspection and feedback?

Of course not! Having people from the organization internally looking your software may help in things that you didn't think of. Especially if you have multiple teams and product owners.

 

 

 

How it helps the other teams?

Having multiple teams working on Product/s its not news. Also what is not also news is that probably the teams are executing the review meeting in different ways.

 

Having people from other teams in the review, may trigger a discussion between them about why the team is executing that way the review and so on. Of course every discussion triggered by an observation its a kind of a small retrospective.. and when there is retrospective in place progress (in any direction) is unavoidable :-).

 

 

 

Someone may ask what differences may be in the way they execute the reviews? The goal is to show the increment right? Well there is always space for errors! Many teams are using slides to do the review which of course is not the live software. Is a software presented via a secondary static format and static formats are.. static.

 

You may have feedback though if you are showing screenshots of you application but you don't demonstrate usability, potential hidden bugs that the reviewers could find otherwise and in the end no ones guarantees that this thing works also outside the slide.

 

The way of walking through the user stories could be a discussion topic between the teams. Some teams chose to go in technical details. Some others show only the demo and not the corresponding User Stories with the acceptance criteria. Maybe they focus to demonstrate to the stakeholder the things he wants to see not spending time to inspect the details of the User Stories. These are topics for discussion which help the team and finally the reviewers to improve the review meeting.

 

How it helps the other Product Owners (if there any)

Multiple product owners for the same product its not news too. How do they coordinate its of course an issue and it depends of many things and also from the way that the work has been split up. Most of the times though in this kind of Product Owners structure, dependencies usually exists between the deliverable s of each team.

 

 

 

Of course during split up of the user stories stories between the teams from the Product Owners this should not be a problem right? Well again there is always space for errors! Having Product Owners from other teams participating to other teams reviews may help to spot potential integration issues or misunderstandings.

 

There is not always the case that the review meeting is able to present all the product parts. For example some products are composed from sub systems which are from their owns products created with different technologies and so on. Even worse when the sub products are scattered in teams in different geographical locations and time zones.

 

The product may has to be presented in different review meetings one per sub product for the reasons mentioned in the previous paragraph. For these reasons Product Owners should not only care about their teams User Stories in the reviews but have an open eye for other team User Stories output because nothing is perfect in the world of software development.

 

How it helps the team to keep high quality?

As I mentioned in previous article, the team may start to feel comfortable if the review meeting are the same few persons or even worse only the Product Owner every time.

 

 

 

Give to the team multiple eyes! Let them present the output of the Sprint to unknown people or to people which are not in every day contact with. This will drive the team to keep a high sense of responsibility and ownership of the deliverable and probably with high quality. No one wants to deliver a poor quality item especially if he/she knows that many will be watching. 

 

Of course its not the way to motivate and make high responsible individuals inside the team but from the other hand why we try Agile? The answer is to satisfy the stakeholder giving them better software.

The best situation is to have teams delivering the best even if no one is reviewing or better if only the reviews are there not to judge but to inspect and adapt as they should!

Please reload

Featured Posts
Please reload

Nikos Raptis -
Agile Coach, Speaker & Developer

I'm a scrum master, speaker and software developer. I love Agile values and principles and...

Contact me

© 2015 Created by Nikos Raptis

  • Google+ - Black Circle
  • Twitter Black Round