Agile Showcases – Guide to effective showcase


Courtsey –

Showcase provides a platform for all stakeholders to get together at the end of the Sprint to review what the team has worked on and provide their feedback on the functionality, which is being built.  As software requirements are subjective hence its important for all stakeholders to view the implementation and ensure what’s built is inline with the expectation. The distributed nature of software development makes showcases challenging and hence it’s pertinent to plan, and prepare for showcase in advance. Based on my experiences of showcase few pointers below could help in planning, and presenting in showcase: 

Purpose of Showcase

  • Demonstrate work done
  • Highlight progress
  • Highlight risks / issues

Benefits of Showcase

  • Get faster feedback
  • Team satisfaction
  • Get new insights on larger business context/usage of the application

What to showcase?

  • Story
  • Spikes
  • Cross Functional Improvements

Guide to effective Showcase


  • In distributed development respect the time zone and schedule the showcase in a convenient time for all members 
  • Always send the agenda for showcase in advance
  • Identify Showcase presenter and scribe 
  • Rotate the showcase presenter and scribe each showcase
  • If possible have Video Conference/interactive tools like webEX, screen sharing, Fuze etc which allow to near f2f communication
  • Share application link (with latest code) for participants to play around if possible


  • Start the showcase by summarizing what you’d cover in showcase before diving into details 
  • Announce some ground rules like cell phones on silent, laptops for all participants in the showcase
  • Always start with bigger picture status – how we’re doing for a feature or a release before diving into individual story/Sprint
  • Before starting demo of an individual story, explain broadly the business value of that story and its role in the feature very briefly
  • Walk through the user journeys – personify the user and talk in terms of what the user would do and what he would see while demo’ing the story. Eg John the librarian wants to issue a book so he first checks if the book if available, he locates the book and lends the book to the borrower.
  • Ensure active participation by making the showcase interactive, ask questions and seek inputs and use humor were appropriate
  • I feel showcase is a great opportunity to highlight risks/dependency 
  • Manage time effectively – allow for healthy conversation however time box them and follow it up
  • Avoid using story numbers, use story titles for talking through a story 
  • Avoid discussing too much technical details in showcase
  • Avoid seeking feedback from just PO/Biz stakeholders, request feedback from all participants


  • Summarize all showcase action items towards the end
  • Share showcase notes with action items to all participants