Hold Show and Tell Sessions
This is a regular meeting that allows teams to celebrate their work and talk about what they’ve learned. Show and Tells are done in the interim during the Sprint while the Sprint Review is done at the end of the Sprint to show all the work completed in the Sprint.
Show and tells are about showing the work done to date. The point is to solicit feedback, so you should include work in progress as well as finished products. Use them to give people a glimpse ‘behind the curtain’ — to humanize the work. It’s also a chance to bring the team together, helping stakeholders and others bond with the team by sharing success, and improving collaboration. These Show and Tells let teams you’re working with know what you’re up to, highlight progress where dependencies exist, and keep teams connected. They also tell stakeholders what you’ve been doing and take their questions and feedback — which is a form of governance.
Having stakeholders participate in Show and Tell is the best form of governance- it encourages transparency. It is more difficult to hide problems when you have to talk about what you’ve learned and show your work. It also supports stronger communication and prevents future issues and bugs before they are developed.
General Rules of the Show and Tell Session:
- This session is to show a specific business function.
- Make sure you prepare before the meeting. Don’t ad lib.
- Make it clear that this is a work in progress.
- Interfaces are ALL stubbed / partially stubbed as appropriate.
- User Interface standards are draft.
- A business discussion about how things should work and to solicit feedback for changes.
- This session is to demonstrate progress against a set of elaboration requirements we have already agreed.
Feedback should focus on:
- Anything that is different from what was agreed to in the use cases (product/process owners mainly).
- Anything obviously missing. Lets’ note these only and do detailed reviews with a smaller audience for specific areas.
- Opinions on UI are notoriously hard to get agreement on as everyone has a different view. These to be fed via the person responsible for UI (Product Owner or UI specialist).
Please discuss any questions or comments with the Product Owner, who will decide if they are valid and prioritize them for inclusion as appropriate
Published May 8, 2018 — Updated May 25, 2018