My team has been doing Scrum with XP-ish practices since 2003. Being a vendor in the Agile space, we’re always testing new ideas and making tweaks to our process. I’ve written about our relatively tight engineering practices when it comes to test-centric development. Nevertheless, about two years ago I made a comment to the team after a particularly rough sprint review; I was disappointed at the quantity of defects and missed “done criteria” surfaced during the sprint review meeting. It ticked me off that the team didn’t seem to find seemingly basic issues until the sprint review.
Taking this feedback, the team innovated an interesting idea: they decided to hold a “dress rehearsal” without the Product Owner (me) a day before the actual sprint review. This rehearsal takes about two hours and each story is vetted in front of the entire team. Each “done” criteria is reviewed and the team takes notes on gaps or issues. The team spends the rest of the day enacting fixes.
The sprint reviews have gone much more smoothly since we adopted the dress rehearsal. I’ve been hesitant to post this idea publicly at the risk of add “yet another meeting” to a Scrum team’s docket. That is until last week when Michael James suggested that this wasn’t a meeting at all, but rather a group testing session. He suggested that even pair programming may be insufficient to catch over-arching integration or system issues. A group system testing session brings a whole bunch of eyes on the big picture features being developed and whether nuanced done criteria are being met by the team’s sprint work.
Does it work? I’d say so. I’ve noticed a marked improvement in the “spit and polish” of our sprint deliverables. The team is thinking big picture and looking at the whole user story, looking through a user’s lens, rather than the myopic unit level a coder operates at 90% of the day.