Merge pull request #112 from labzero/design-feedback-update

Design feedback update

continuous_delivery/demo_guide.md

@@ -1,42 +1,44 @@
-# Sprint Demo Guide
+# Sprint Review
 
-## Overview
-Showing your work and the work of your team to a broader audience uses some different skills than we might use when building products. Let's talk about the most important tips we keep in mind when running demos. 
+## What is a sprint review?
 
-## Be prepared
-Go through all of the delivered and accepted tickets to make sure you know what was done and how to show it. 
+A regular demonstration of the value delivered in a sprint.
 
-Take notes to use during the demo so that you can cruise through the delivered work as a story. Some back and forth is okay but you should try to minimize it. 
+## Why is a sprint review needed?
 
-The main trick is to try to tell the audience about as much work done on a screen as you can while still keeping the story simple.
+Stakeholders and interested parties see actual progress being made, and give feedback early and often into the product and outcome.
 
-We often do a pre-demo meeting for 15-30 minutes where the product owner and dev team meets to review the work for the "release". This is a great place for the demoer to do their homework with the other devs and product owner there to answer questions on how to demo things.
+## When does the sprint review take place?
 
-## Connect with the audience
-The demo is the time to show the value that has been delivered. Tell a story and assume that folks need more context than you and your teammates would use.
+At the end of every sprint.
 
-Know your audience and adjust your demo to cater specifically to them. If you are demoing to non-technical people, don't dive into the weeds of how something was done, or why it was difficult or easy to implement. Instead, focus on the value that has been added to the product or user, for example.
+## Who attends the sprint review?
 
-Make sure the audience is with you. It is okay to look at them, in the eye, and is encouraged. :) 
+**Preparation** - The [demo script](/project_kickoff/sprint_review_template.md) is prepared by the Product Manager and shared with the squad before the demo.
 
-## Keep it organized
-Someone other than the demoer should be playing scribe for the demo, but if not make sure to jot larger conversations down for later discussion. Don't let some feedback from the audience turn into a several minute group design session. 
+**Attendees** - All relevant stakeholders are invited to the demo. The whole squad attends the demo.
 
-## Check yourself
-There are a handful of common things that a demoer can do and say that don't show well. Be mindful to avoid things like:
+**Demo** 
+- At the beginning of the demo the Product Manager provides context.
+- An Engineer then demos the work delivered (ticket by ticket, as listed in the script). Take turns each demo so the whole engineering team is able to practice their demo skills.
+- A member of the squad takes notes on feedback.
 
-* Extra mouse clicks 
-* Fast or extra scrolling 
-* "There's not much to show you today."
-* "We didn't get as much done as we wanted to."
-* "...but there's nothing for me to really show you.."
+**Optional Design Demo** - Many teams find it valuable to give a preview of approved, ticketed designs that are slated for delivery. Other teams may use this time to communicate highlights from design research. This section is intended to give the team visibility into design tasks and should be kept brief.
 
-## Best practices
-* Arrive 5-10 minutes early to setup your AV.
-* Turn on your computer's [Do Not Disturb](https://www.youtube.com/watch?v=KxHMpviBlaY) mode
-* Close all communication apps, like Slack, Messages, Email
-* Draw a circle around navigation elements with your mouse before clicking to draw attention to where the action is happening and give the audience time to follow along.
-* Zoom in (⌘ +) to a level that makes text readable to everybody. (Especially when showing things like a Pivotal backlog)
 
-## Take turns
-The demoer role should be shared by taking turns each week to encourage new styles and a safe place for learning.
+## Demo Best Practices
+- **Focus on value** - The demo is the time to show the value that has been delivered. Center your story on value rather than tasks. Connect the story to the persona who would see value from this work.
+- **Know your audience** - Adjust your demo to cater specifically to them. If you are demoing to a non-technical or mixed audience, don't dive into the weeds of how something was done, or why it was difficult or easy to implement. Instead, focus on the value that has been added to the product or user, for example.
+- **Reduce distractions** - Keep your screen focused on what the grou needs to see.
+  - Turn on your computer's [Do Not Disturb](https://www.youtube.com/watch?v=KxHMpviBlaY) mode
+  - Close all communication apps, like Slack, Messages, Email
+  - If sharing a broswer window, limit the open tabs to those relevant to the demo
+  - Draw a circle around navigation elements with your mouse before clicking to draw attention to where the action is happening and give the audience time to follow along.
+  - Zoom in (⌘ +) to a level that makes text readable to everybody. (Especially when showing challenging to read items like a backlog)
+
+
+## Related content
+
+- [How to run a perfect sprint demo](https://labzero.com/blog/how-to-run-a-perfect-sprint-demo)
+- [Five rules for a seamless (and effective) demo](https://labzero.com/blog/five-rules-to-a-seamless-and-effective-demo)
+- [What to do when you actually get feedback during a demo](https://labzero.com/blog/breathe-what-to-do-when-you-actually-get-feedback-during-a-demo)

index.md

@@ -6,13 +6,14 @@ layout: page
 
 Welcome to Lab Zero's resource library. These guides offer insights into our best practices for product development processes, playbooks, languages, and tools. They represent our evolving knowledge and expertise. By sharing them, we aim to provide others with the benefits of our experience and  a glimpse into what it's like to work with us.
 
-Feel free to explore, and if anything catches your attention or raises questions, we're here and eager for your feedback.
+Feel free to explore, and if anything catches your attention or raises questions, [we're here and eager for your feedback](https://labzero.com/contact).
 
 
 ## Project Kickoff
 
 - [Project Charter](project_kickoff/project_charter.md)
 - [Sprint Ceremonies](project_kickoff/ceremonies.md)
+- - [Sprint Review Guide](continuous_delivery/demo_guide.md)
 - [Definition of Ready](project_kickoff/definition-of-ready.md)
 - [Definition of Done](project_kickoff/dod.md)
 - [Team Norms](project_kickoff/team_norms.md)
@@ -42,7 +43,7 @@ Feel free to explore, and if anything catches your attention or raises questions
 - [Testing Strategy](continuous_delivery/testing_strategy.md)
 - [Git Commit Guide](continuous_delivery/commit_guide.md)
 - [README Guide](continuous_delivery/readme_guide.md)
-- [Sprint Demo Guide](continuous_delivery/demo_guide.md)
+
 
 ## Technical Guides
 

project_kickoff/dod.md

@@ -22,5 +22,5 @@ You will never be "done", and your version of done will vary by feature at diffe
 If you do all of that and things look good-enough to the business group, ship and repeat!
 
 
- ## Related content
+## Related content
 [Essential Working Agreements: Ready and Done](https://labzero.com/blog/essential-working-agreements-ready-and-done) blog post

project_kickoff/sprint_review_template.md

@@ -0,0 +1,43 @@
+# [Client] Sprint Demo & Retrospective
+
+---
+***🎥 Start recording***
+---
+
+## Attendees
+Lab Zero: 
+[Client]: 
+
+###Intro/Summary
+High level context for the sprint. Include any big points of interest.
+
+## Value delivered this sprint
+- Bullet appointed summary.
+
+## Demo
+### Features
+[ticket number and link] [story name]
+####Tasks
+[ticket number and link] [task name]
+### Bugs
+[ticket number and link] [bug name]
+
+### Design demo (optional)
+[initiative name] [type: design or research]
+
+## [Client] Questions and Feedback
+
+
+---
+
+## Sprint review
+### Outcomes
+- 
+
+### What worked well?
+- 
+
+### What can be improved?
+- 
+
+### Notes