About Product Demonstration

小咪咪 2022-01-09 11:04 138阅读 0赞

I received a invitation letter from US team about a sprint demonstration. Although I couldn’t join it (it is very early morning of my time :p), I went through the mail with detail (I should do this before actually but I missed lots of time) and found the introduction for product demonstration was very helpful. So I copied it here.

<table> 
 <tbody> 
 <tr> 
 <td> Product Demonstration At the end of a Sprint, the team presents the product increment that it has built in the form of a demonstration of the product working as it exists at that time. The Product Owner, customers, users, management, and other interested stakeholders inspect the Product and the progress toward the Product’s goals. Based on the Product Demonstration, adaptations can be made to the project. During the meeting, everyone visualizes the demonstrated product functionality working in the customer or user environment. As this is visualized, they consider what functionality might be added in the next Sprint. The product increment is the focal point for brainstorming. As the team demonstrates the product increment, it helps the attendees understand the strengths and weaknesses of the product increments, and the difficulties and successes experienced delivering it. Product Demonstration Rules 
 <ul> 
 <li>Functionality that is not Done cannot be presented. 
 <ul> 
 <li>Done means the code has been tested, checked-in, and tested in the context of the product. </li> 
 <li>Done means that everything that people can think of for their software to be maximum quality and shippable </li> 
 <li>Done means there is no known newly-created technical debt being carried forward that has not been explicitly agreed to in advance in conversations between the Team, Product Owner, and any other stakeholders (other Teams, Technical Architects, etc.).</li> 
 </ul></li> 
 </ul>(Technical debt is the unfinished work the product development team accumulated from previous releases or Sprints. This debt can include (but is not limited to) design debt, where the design is insufficiently robust in one or more areas; development debt, where pieces of the code are missing, or known to be fragile or broken; and testing debt, where tests were not developed and/or run against the code. See also <a href="http://martinfowler.com/bliki/TechnicalDebt.html" rel="nofollow">http://martinfowler.com/bliki/TechnicalDebt.html</a>). 
 <ul> 
 <li>Artifacts that aren't working software cannot be presented, except as needed to support understanding of the work products.</li> 
 </ul> 
 <ul> 
 <li>Functionality should be presented from the Team members’ workstations, and executed from the environment that is closest to production - usually a quality assurance environment.</li> 
 </ul> 
 <ul> 
 <li>Stakeholders can identify functionality that wasn't delivered, or wasn't delivered as expected, and request that such functionality be placed in the Product Backlog for prioritization, as well as identify any new functionality that occurs to them as they view the presentation, and request that the functionality be added to the Product Backlog for prioritization.</li> 
 </ul> 
 <ul> 
 <li>Ideally, the Team should not spend more than an hour preparing for the Product Demonstration.</li> 
 </ul> 
 <ul> 
 <li>Stakeholders are free to voice any comments, observations, or criticisms regarding the increment of potential shippable product functionality between presentations.</li> 
 </ul>Product Demonstration Agenda 
 <ul> 
 <li>The Product Demonstration starts with a Team member presenting the Sprint goal, the Product Backlog committed to, and the Product backlog completed. Different Team members may discuss what went well and what didn't go so well in the Sprint. </li> 
 <li>The majority of the Product Demonstration is spent with Team members presenting functionality, answering stakeholder questions regarding the presentation, and noting changes desired. </li> 
 <li>At the end of the Product Demonstration: 
 <ul> 
 <li>The stakeholders are polled, one by one, to get their impressions, any desired changes, and the priority of these changes. </li> 
 <li>The Product Owner discusses with the stakeholders and the Team potential rearrangement of the Product Backlog based on the feedback. </li> 
 <li>The ScrumMaster asks the Product Owner if she or he would like to ask for a Release Sprint to implement the demonstrated functionality, alone or with increments from previous Sprints. </li> 
 <li>The ScrumMaster asks the Product Owner if she or he will authorize another Sprint for the Team to continue the Project. </li> 
 <li>The ScrumMaster announces the place and date for the next Product Demonstration to the Product Owner and stakeholders.</li> 
 </ul></li> 
 </ul> Other possible Product Demonstration results 
 <ul> 
 <li>As needed, the Product Owner will: 
 <ul> 
 <li>Restore unfinished functionality to the Product Backlog and prioritize it. </li> 
 <li>Remove functionality from the Product Backlog that the Team unexpectedly completed. </li> 
 <li>Reprioritize the Product Backlog to take advantage of opportunities that the demonstrated functionality presents.</li> 
 </ul></li> 
 <li>The Product Owner may also: 
 <ul> 
 <li>Choose not to proceed further with the project, and not authorize another Sprint. </li> 
 <li>Request that the project progress be sped up by authorizing additional Teams to work on the Product Backlog. </li> 
 <li>Work with the ScrumMaster to reformulate the Team.</li> 
 </ul></li> 
 </ul></td> 
 </tr> 
 </tbody> 
</table>

转载于:https://www.cnblogs.com/RelaxTintin/archive/2009/07/24/1529966.html