| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

Sprint Reviews - Who are they really for

Page history last edited by Generic Account 11 years, 5 months ago

Hosted by: Bob Schatz

 

We had a discussion about the Sprint Reviews. As I have worked with many companies around the world, and have the experiences from the Primavera adoption of Scrum, I have noticed some misuse and/or abuse of the Sprint Review process. The Sprint Review is a key component in the Inspect & Adapt cycle.

 

  • Sprint reviews are for the end-users to provide feedback on the product under development
  • The Product Owner WITH the Scrum Team presents to the end users and stakeholders
  • Key point the the Product Owner should be presenting THEIR product
  • PO should be involved throughout the sprint
  • Show only what is DONE by the Definition of Done
  • PO sets expectations of DEMO with introduction of what was worked on AND the product/release burndown
  • Team presents the completed user stories
  • Opportunity for the team to "get to know" the end users by interacting with them in the context of the user story demonstration. This gets the "face of the end user" or Voice of the customer in the scrum team's head during development....produces better software.
  • Gives the team some recognition, sense of accomplishment, team pride
  • Launching pad for the next sprint
  • Don't assume you can't get an end user....ASK!
  • Be careful who you choose; make sure they are a good representative of the end user base; make sure they know their responsibility
  • If you can not get them to come in physically, the hook them in virtually
  • Beta reseases give great end user feedback. With agile its not the basic bugs anymore. You are not doing Betas to get your user to find defects. It's about usability, performance, randomness, etc.  Final validation that solution is ready for General release.
  • Get to the REAL end users; not stakeholders. Example: An end user's manager may have good input, but it will be from another perspective. We want the person that relies on the product to do their job successfully.
  • For complex products/applications, you may want to think about "theme-ing" the sprints. This will keep the user feedback focused 

 

THE ULTIMATE GOAL IS TO GET THE MOST VALUABLE FEEDBACK ON THE APPLICATION. ASK YOURSELF, WHAT'S THE BEST WAY TO DO THAT??

 

Comments (0)

You don't have permission to comment on this page.