Continuous improvement is a key principle of Scrum. Yet, though most Scrum teams conduct a sprint review ineffectively often leading to sprint review taking long time, sprint review going out of focus, inconclusive in the end, teams and Product Owners not coming to conclusion. In my experience, some of the common causes for this:
- Definition of Done not identified properly
- Objective acceptance criteria for non functional requirements
- Lack of clear sprint goals
- Involvement of Stakeholders
- Time box or Sprint review meeting time taking long time
- Attendance of team members
1. Definition of Done not identified properly:
Many times Scrum teams and Product Owners conduct the sprint review without clarity on when are the scrum teams done with their work. Establishing the agreement on definition is done is vital for the success of the sprint reviews. It is better teams identify the “Definition of Done (DOD)” before the sprint and have an agreement with the Product Owners.
Sample of “Definition of done”:
1. Working Software + Demo
- Unit testing should be completed.
- Code review should have been completed
- Include any specific non functional requirement such Response time, No of users to be supported concurrently etc
- No Critical defects
- Test Cases + Test Report showing successful tests.
- Functionalities review by Product Owner
- User Manual ( On-line Help)
- Design(Internal Use)
- Release Notes
2. Objective acceptance criteria for non functional requirements:
The scrum team should have clarity on what needs to be tested for user stories. This can be done effectively if the team has clarity on what are the acceptance criteria for non functional requirements the user or product owner expect to be met by the agile team. The non functional requirement should not be subjective, as far as possible. Hence team should ensure that Product Owner defines the objective non functional requirements in acceptance criteria as much as possible
- What is the response time for GUI screens?
- No of users supported by the functionality?
3. Lack of clear sprint goals:
The central point of discussion is the Product Increment completed during the Sprint. A demonstration of the Product Increment is common in sprint review meeting. The sprint goal should be decided by the Scrum team as an outcome of the sprint planning exercise and the commitment has to be done by the team to the Product Owner, before the sprint. The ability to split user value into small, vertical, testable user stories is essential to agility, but it can be difficult to see the forest for the trees.
4. Involvement of Stakeholders:
The Scrum Master organizes and facilitates the Scrum meetings, including the Sprint Review. The Scrum Master ensures that all the stakeholders of the Scrum Team are invited to the Sprint Review. The list of stakeholders invited should include, most importantly, end users of the product and / or actual external customers who would buy the product. The Scrum Team presents the product increment during the demo portion of the Sprint Review. This presentation allows the stakeholders to give immediate feedback on the product increment including new functionality, quality, and desired future direction. If the stakeholders are not invited, then it is possible that important feedback will be missed and the Product Owner may create incomplete or sub-optimal Product Backlog.
5. Time box or Sprint review meeting time taking long time:
As per the core scrum the guideline for sprint reviews are Time-boxed to 1 hour per per week of Sprint length
- (i.e. 2 week sprint = 2 hours, 4 week sprint = 4 hours, and so on)
Often team spends quite a long time without arriving at any conclusion. One of the mistakes done by the team and Product owner done, is thinking the sprint review as sort of user acceptance testing. Then they become very strict and too serious to validate what has been done or not done. Sprint review meeting should be treated as informal and fun. In this process there arises lot of back and forth discussion, justification etc. Whole idea of sprint review is to “Use frequent Inspect and adapt” approach, so that team takes the feedback frequently and adapt and adjust their approach to produce potentially shippable product increment.
6. Attendance of team members
The Sprint Review meeting supports the Scrum value of Openness and the principle of inspect and adapt. This rule of Scrum also aligns with the Agile Manifesto principles “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. Delivering the value to the customers is the key. Complete attendance of all Scrum team members allows for lot of openness among team members and effective communication of feedback from stakeholders reviewing the product increment. If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and inspect and adapt becomes compromised. The successful delivery of the valuable software requires full commitment on the part of the whole team. Lack of attendance / participation impacts the openness and inspect and adapt will lack effectiveness.