04_Sprint Review Meeting - Facts & Rules

Source:  Agile Project Management with Scrum by Ken Schwaber

 

Duration:

 

1.             Time-boxed to 04 Hours (Four Hrs).

2.             Preparation Time Should not be more than 1 hour

 

Attendees:

 

3.             ScrumMaster should attempt to determine the number of people who expect to attend the Sprint review meeting and set up the meeting to accommodate them.

4.             Team members &  Stake Holders (Specially PO)  – Team  members  presenting functionality, answering Stakeholder questions.

 

Review Content:

 

5.             Functionality that isn’t “done” cannot be presented.

6.             Present to the Product Owner and stakeholders functionality that is “done”

7.             Although the meaning of “done” can vary from organization to organization, it usually means that the functionality is completely engineered and could be potentially shipped or implemented.

8.             Artifacts that aren’t functionality cannot be presented except when used in support of understanding the demonstrated functionality.

 

 

Review Procedure

 

9.             Sprint review starts with a Team member presenting the Sprint goal, the Product Backlog committed to, and the Product Backlog completed.

10.         Majority of the Sprint review is spent with Team members presenting functionality, answering stakeholder questions regarding the presentation, and noting changes that are desired.

11.         Stakeholders are free to voice any comments, observations, or criticisms regarding the increment of potentially shippable product functionality between presentations.

12.         At the end of the Sprint review, the Scrum Master announces the place and date of the next Sprint review to the Product Owner and all stakeholders.

 

 

Action Items – At The End

 

13.         At the end of the presentations, the stakeholders are polled, one by one, to get their impressions, any desired changes, and the priority of these changes.

14.         Stakeholders can identify functionality that wasn’t delivered or wasn’t delivered as expected and request that such functionality be placed in the Product Backlog for prioritization.

15.         Product Owner decides What is done and What is not.

16.         Product Owner & Team discuss remaining PB, determine what to do next and do prioritization.

17.         Different Team members can then discuss what went well and what didn’t go well in the Sprint.

 

 

Keep Blogging...

 

Regards,

Arun Manglick