One of the many frequent questions I usually get asked is – Why Agile? What are its benefits? Although, the answer to this question can lead to a never ending debate, I like to begin my answer with – Agile helps improve quality. How you ask? Let me explain. Software Quality reflects how well a deliverable complies with the functional and non-functional requirements. Agile teams shoulder the responsibility of maintaining this quality, but they aren’t alone. Customer representatives and end-users collaborate with Agile teams to provide rapid feedback in order to correct any mistakes early in the project. This rapid feedback is one of the biggest reasons of improved quality on Agile projects and Sprint Review meeting is one Scrum ceremony where it can be extracted efficiently. The challenge is extracting it from the right individuals especially when they are introverts.
When it comes to feedback, humans rarely provide positive ones. We all do it, whether it’s a recent purchase or a service received; software reviews are no different. When demonstrating a Sprint’s deliverable, we usually invite all the relevant stakeholders for review. Many attend and a few don’t. A Product Owner (customer representative) accepts or rejects deliverable as they are being demonstrated and change requests (mistakes) are noted to be added to the product backlog. But is it enough to to capture these observations and move on? Well, in an ideal world, yes! In the real world, we forget to capture the positive feedback that identifies the good practices to be continued. No bad feedback is not good feedback. A bigger challenge is extracting information from introvert end-users who are like dormant volcanoes waiting for post-production crisis.
Below are 3 practices I believe can help teams overcome these challenges and help execute a Sprint Review to receive constructive feedback.
1) Demo Preparation:
Most Agile teams spend an hour or two planning the demonstration. Basically, what can they demonstrate, how to demonstrate, who demonstrates, sequence of demonstration, test data collection, and so on. But since teams demonstrate deliverable after every Sprint, chances are that the team members become comfortable (or bored) with it and start cutting corners. Not enough preparation becomes their Achilles heel and a recipe for disaster. Scrum Masters must make sure that this doesn’t happen. A good way to avoid this is by asking the team members to prepare questions to be asked to the stakeholders during the review. After all, reviews are for validating the deliverable against the requirements. Questions can be directed to specific (may be introvert) end-users to verify if the deliverable helps them fulfill their job. Getting an explicit thumbs-up from the stakeholders matter.
2) Usability & User Testing:
Not many teams (Agile or otherwise) perform usability tests post implementation. Although the current trend is to begin focusing on UX (User eXperience) much prior to implementation, post implementation usability tests with real end-users in a staging environment has its own benefits. For starters, users can provide their comments on the non-functional requirements like performance and intuitiveness of the deliverable. Many agile teams automate their functional tests and simulate load for stress tests, but not all human emotions can be automated; that’s where usability and user tests come in. It can be a good practice for your team if you can invite 2 to 3 real end-users before every Sprint Review and ask them to run a few scenarios designed by your team without any intervention from the team. The team members can silently observe the happiness and frustration levels of the end-users and discuss it during the Sprint Review meeting. This process does ask for some time investment in recruiting new users for each test session and formulating the scenarios, but reduces the need to train end-users later.
3) Post Review Survey:
Surveys are a good way to gather more focused feedback from your customers. Scrum Masters can formulate a small (online) survey post Sprint Review to make sure that the stakeholders have left the meeting in a happy state. A good mix of closed and open ended questions designed specifically around the Sprint deliverable can help collect positive and negative feedback from the stakeholders. Care must be taken to design questions around the deliverable and not the team member’s performance with the deliverable. Although data collected from a survey will not impact the accepted or rejected Sprint deliverable, it can help the Product Owner and Business Analysts to start a conversation with the stakeholder to improve the quality further.
These 3 practices can help improve your Sprint Reviews and make them much more productive. Although these practices require some changes in your current processes, the benefits surely outweigh the investments. And since you’re improving the interaction between the team and the stakeholders, individuals and interactions over processes and tools is enough to motivate and move the big rocks.