The showcase is the moment where as proud parents you show your baby to the eager throng and bask in the glory of a job done well. Hmm. Well, some nods of approval and appreciative murmurs is often more like it, but the showcase is certainly the high point of our job satisfaction at SSA.
In ‘pure’ Agile, where the client is sitting next to the developers several times a day (no, we don’t know an agency that does that either) then the showcase is actually a formality where stories that have already been accepted by the product owner during the sprint are gathered up and demonstrated end-to-end to the wider stakeholder group.
As an agency we’ve modified this idea a bit by categorising stories into 3 types which drive how the stories are dealt with relative to the showcase:
We are confident enough in our understanding of what the client wants that we will showcase the story without any interim feedback from the client, with the expectation that any feedback can be addressed within the overhead time in the next sprint (i.e. feedback will be minimal or simple to address). These stories are often UI-based so that the client can accept the story within the session after seeing the demo.
We recognise that the implementation would benefit from an interim steer from the client during the sprint. Engineers will suggest one or two ‘checkpoints’ when the client’s input would be beneficial to de-risk our implementation. Each checkpoint is usually done remotely in a short screen-share session lasting perhaps 15 minutes.
This is useful in conjunction with one of the two categories above, when we recognise that the client will not be able or willing to accept the story within the showcase session but will need some extended user-acceptance testing in the days following the session to fully explore and test the feature.
In all cases the feature is demo’d in the showcase with the objective that the client will accept the story as ‘done’ subject to some feedback that is manageable within the usual overhead time of the next sprint.
Showcase top tips
This process runs quite predictably at SSA now and the team have a high acceptance rate and manageable feedback overheads, but it has certainly taken a while to learn the upstream actions that are needed to achieve this.
Here are 7 tips we’ve picked up along the way:
- Spend time to make sure the holy trinity of client, analyst and engineer are all happy with the story elaboration before implementation starts. It might sound like a concession to waterfall, but if stories are kept short (3 days max) then a bit of ‘documentation’ avoids misunderstandings all round.
- Set expectations about what is likely to make it into the showcase at the start of the sprint. Again, it’s not pure Agile (which would say fix the time and see how many features you can fit in) but we think it sits better in an agency model. Sometimes you have to explain to a client why you run out of time, but other times you balance by over-delivering.
- Have the person that gathered the requirements also lead the showcase. It’s nice to involve the engineers too to promote that team feel but ‘closing the BA/QA loop’ inspires confidence that the story implementation is fit for the original purpose.
- Capture feedback on a shared whiteboard or screen during the presentation. It’s reassuring to everyone if the points are captured using words that everyone can agree right there and then. There is always feedback, but doing feedback on feedback is a fail.
- Plan the showcase narrative and put stories in a logical order from a user’s perspective. This helps comprehension and speeds up the session. For our more complex systems we may even do a ‘dress rehearsal’ of the showcase one or two days prior – it’s interesting what issues this can flush out and it certainly increases confidence on the day!
- Make use of the classic 3-part presentation format to a) review the list of stories we expect to see, b) present each story implementation, and c) recap the stories we’ve presented and any feedback points.
- For stories that are going into extended UAT after the showcase, set a time period when UAT will take place and a date when the acceptance decision and feedback will be returned. This prevents a story from getting ‘lost’ in UAT which can mean the story never gets officially accepted and that can raise its head later when the story is no longer current.
Well these are a few of the guidelines we apply to an SSA showcase – every Agile team is different – but if you are an Agile practitioner then I hope there is something here you find useful, and if you are an SSA client then you know a bit more about what to expect!