agile# How to Use Overnight Delivery Innovation to Create Effective Sprint Reviews in Entertainment Services (1/37)
An entertainment services company running XP with a small team has a sprint review problem. The company provides a talent management platform that helps entertainment agencies manage artists, bookings, and contracts. It has been around for twenty-two years and has 840 employees. The product development organization for the new contract negotiation module has four people running XP. One small team. Four people. (2/37)
The sprint reviews are ineffective. Stakeholders don't attend. When stakeholders don't attend, they don't see the work. When they don't see the work, they don't give feedback. When they don't give feedback, the team builds the wrong thing. When the team builds the wrong thing, the contract negotiation module doesn't meet stakeholder needs. When it doesn't meet stakeholder needs, stakeholders reject the work. When stakeholders reject the work, the team has to redo it (3/37)
. That wasted the company $67,000 last quarter. That was 23% of the quarterly budget for the contract negotiation module.
The sprint reviews need to be effective. (4/37)
Fred Smith built FedEx on overnight delivery innovation. The insight was simple. Smith realized the biggest problem in package delivery was treating every package the same. Urgent packages moved at the same speed as non-urgent ones. That meant urgent packages were late. Late packages made unhappy customers. Unhappy customers left. That killed companies. (5/37)
Smith attacked the problem. He created overnight delivery innovation based on one principle: Guarantee the delivery. Then engineer the system to meet the guarantee.
He made a promise. He promised overnight delivery. Customers expected it. So he engineered the system. He created a hub-and-spoke model. Every package went through a central hub. Packages were sorted quickly. Packages were delivered overnight. That built FedEx. (6/37)
When Smith designed the FedEx tracking system, he didn't treat every package the same. He guaranteed delivery. He promised customers could track their packages. Customers expected it. So he engineered a tracking system. Customers could see where their packages were. That built FedEx. (7/37)
Smith applied the same thinking to every part of the business. When he designed the sorting system, he guaranteed packages would be sorted in under two hours. He engineered an automated sorting system. Packages were sorted in under two hours. That built FedEx.
For this entertainment services company, the sprint review problem is the same. The team treats every sprint review the same. Reviews are generic. Stakeholders aren't engaged. Stakeholders don't attend. That costs $67,000. (8/37)
Smith's overnight delivery innovation says: guarantee the delivery. Then engineer the system to meet the guarantee. That creates effective sprint reviews. That saves the company.
## The Core Principle (9/37)
Smith's overnight delivery innovation was built on a simple insight. The best way to create effective sprint reviews is to stop treating every sprint review as a generic demo that may or may not engage stakeholders. Start guaranteeing that every sprint review delivers specific value to specific stakeholders. Engineer the review format, the invitation process, and the feedback collection to meet that guarantee. Stakeholders attend because they know exactly what they'll get (10/37)
. The team gets actionable feedback because the review is designed to produce it.
Smith didn't build FedEx by treating every package the same and hoping urgent packages would arrive on time. He built it by guaranteeing the delivery and engineering the system to meet the guarantee. The guarantee was a promise. The engineering kept the promise. Keeping the promise built FedEx. (11/37)
For this entertainment services company, the sprint review problem is the same. Treating every sprint review the same costs $67,000. Smith's overnight delivery innovation says: guarantee the delivery. Then engineer the system to meet the guarantee. That creates effective sprint reviews. That saves the company.
## Four Steps to Apply Overnight Delivery Innovation
1. Guarantee the Delivery by Defining a Specific Value Promise for Each Sprint Review (12/37)
Smith guaranteed the delivery at FedEx. He made a promise. Customers expected it. He had to deliver. That built FedEx.
You should do the same. Define a specific value promise for each sprint review. State exactly what stakeholders will see and exactly what feedback the team needs. Stakeholders know what they're getting. The team knows what it needs. (13/37)
For this entertainment services company, the specific value promise might look like this. The XP coach defines it. It's a one-paragraph statement with two parts. (14/37)
Part one: what stakeholders will see. The demo is specific. Stakeholders know what they'll see. They can decide if they want to attend. For sprint seven, the promise might be: You will see a working prototype of the contract clause library that lets agents search and filter clauses by type and jurisdiction. You will see how agents can drag and drop clauses into a contract. You will see how the system flags conflicting clauses. (15/37)
Part two: what feedback the team needs. The feedback is specific. Stakeholders know what to focus on. They give useful feedback. For sprint seven: We need feedback on three things. One: Is the search and filter functionality intuitive? Two: Does the drag and drop interaction feel natural? Three: Is the conflict flagging clear and actionable? (16/37)
The specific value promise is written before the sprint review. The team plans the review. The review is focused. The review is effective. The promise is sent to stakeholders with the invitation. Stakeholders know what they'll get. Stakeholders attend.
Last quarter, the specific value promise was defined for every sprint review. Stakeholders knew what they would get. They attended. The team got feedback. The team built the right thing. That saved the company $18,000. (17/37)
For an XP team of two to five, the specific value promise should have at least two parts: what stakeholders will see and what feedback the team needs. Send it with the invitation. Make it part of the team's sprint review planning.
2. Engineer the System by Designing a Sprint Review Format with Three Segments
Smith engineered the system at FedEx. He kept the promise. That built FedEx. (18/37)
You should do the same. Design a sprint review format with three segments that lasts no more than thirty minutes. The review is structured. It respects stakeholder time. It produces actionable feedback.
For this entertainment services company, the format might look like this. The XP coach designs it. It's a template with three segments. (19/37)
Segment one: Context. Five minutes. Read the value promise so stakeholders remember why they're here. Include a brief two-minute recap of the sprint so stakeholders understand the demo.
Segment two: Demo. Fifteen minutes. Show working software. Stakeholders see the work. They can give feedback. The demo is live. Stakeholders see real functionality. They trust the demo. They give honest feedback. (20/37)
Segment three: Feedback. Ten minutes. Collect feedback. Ask questions. Stakeholders give specific feedback. Use the three questions from the value promise. The feedback is focused. The feedback is actionable.
Total time: thirty minutes. The review is short. Stakeholders respect it. Stakeholders attend. (21/37)
Last quarter, the sprint review format was designed in a one-day effort. The template had three segments. The total time was thirty minutes. Stakeholders attended. The team got feedback. The team built the right thing. That saved the company $17,000.
For an XP team of two to five, the format should have at least three segments: context, demo, and feedback. Total time should be no more than thirty minutes. Make it part of the team's sprint review planning. (22/37)
3. Track the Package by Sending a Follow-Up Summary Within One Hour
Smith tracked the package at FedEx. Customers could see where their packages were. That built FedEx.
You should do the same. Send a follow-up summary within one hour of the sprint review. Document the feedback, the decisions, and the next steps. Stakeholders can see their feedback was heard. The team has a record. (23/37)
For this entertainment services company, the follow-up summary might look like this. The XP coach sends it. It's an email sent within one hour while the feedback is fresh. It has three sections. (24/37)
Section one: Feedback received. Document what stakeholders said. The team has a record. For sprint seven: Stakeholder one said the search and filter functionality is intuitive but the filter labels are confusing. Stakeholder two said the drag and drop interaction feels natural but the drop zone is too small. Stakeholder three said the conflict flagging is clear but the conflict resolution suggestions are missing. (25/37)
Section two: Decisions made. Document what was decided. The team has a record. For sprint seven: Decision one: Rename the filter labels to match industry terminology. Decision two: Increase the drop zone size by 50%. Decision three: Add conflict resolution suggestions to the next sprint. (26/37)
Section three: Next steps. Document what will happen. The team has a plan. For sprint seven: Next step one: The team will rename the filter labels. Next step two: The team will increase the drop zone size. Next step three: The team will add conflict resolution suggestions to the sprint eight backlog.
The follow-up summary is sent to all stakeholders. All stakeholders know. All stakeholders trust the team. All stakeholders attend the next review. (27/37)
Last quarter, the follow-up summary was sent for every sprint review. Stakeholders knew their feedback was heard. They trusted the team. They attended the next review. The team got feedback. The team built the right thing. That saved the company $16,000.
For an XP team of two to five, the follow-up summary should have at least three sections: feedback received, decisions made, and next steps. Send it within one hour. Make it part of the team's sprint review process. (28/37)
4. Iterate by Running a Feedback Loop After Every Fourth Sprint Review
Smith iterated at FedEx. FedEx got better. That built FedEx.
You should do the same. Run a feedback loop after every fourth sprint review. Review the review format, the value promise, and the follow-up summary. Base changes on what's working and what's not. The reviews get better every four sprints. (29/37)
For this entertainment services company, the feedback loop might look like this. The XP coach runs it. It's a twenty-minute meeting after every fourth sprint review. It has three parts.
Part one: Review the review format. Seven minutes. Check if the format works. Adjust it if needed.
Part two: Review the value promise. Seven minutes. Check if the promise is specific enough. Adjust it if needed. (30/37)
Part three: Review the follow-up summary. Six minutes. Check if the summary is useful. Adjust it if needed. (31/37)
Last quarter, the feedback loop was run three times. The review format was reviewed three times. Two updates were made. Update one: a new stakeholder questions segment was added. Stakeholders could ask questions. They were more engaged. Update two: the value promise was made more specific. Stakeholders knew exactly what they would get. They attended. The reviews were better. That saved the company $16,000. (32/37)
For an XP team of two to five, the feedback loop should happen after every fourth sprint review. It should have at least three parts. It should update at least one artifact per quarter. Make it part of the team's sprint review process.
## Closing on Guaranteeing the Delivery
Fred Smith didn't build FedEx by treating every package the same. He built it by guaranteeing the delivery, engineering the system, tracking the package, and iterating. (33/37)
For this entertainment services company running XP with a small team of two to five, creating effective sprint reviews requires the same overnight delivery innovation.
Guarantee the delivery. Define a specific value promise for each sprint review that states exactly what stakeholders will see and what feedback the team needs. Send it with the invitation. (34/37)
Engineer the system. Design a sprint review format with three segments that lasts no more than thirty minutes. Context, demo, feedback.
Track the package. Send a follow-up summary within one hour that documents feedback, decisions, and next steps.
Iterate. Run a feedback loop after every fourth sprint review. Update at least one artifact per quarter. (35/37)
Start by having your XP coach define the specific value promise for the next sprint review. Then design the format, send the follow-up summary, and run the feedback loop after every fourth review. Your 840-employee company stops losing $67,000 per quarter on rejected work (36/37)
. Because you learned to create effective sprint reviews from a delivery innovation pioneer who proved that the best way to get stakeholders to attend and give feedback is to stop treating every review the same and start guaranteeing the delivery and engineering the system to meet the guarantee.
#Agile #XP #SprintReview #ExtremeProgramming #AgileCoaching #SoftwareDevelopment #StakeholderEngagement #ProductDevelopment #AgileTransformation #DevBestPractices (37/37)