<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>sprint reviews | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/sprint-reviews/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Tue, 30 Jan 2018 18:00:47 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	

<image>
	<url>https://www.scrumexpert.com/wp-content/uploads/favicon.png</url>
	<title>sprint reviews | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Four Steps for a Successful Scrum Product Demo</title>
		<link>https://www.scrumexpert.com/knowledge/four-steps-for-a-successful-scrum-product-demo/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 30 Oct 2017 14:05:55 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product owner]]></category>
		<category><![CDATA[sprint reviews]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4707</guid>

					<description><![CDATA[Sometimes as software developers we think that if we build a good product, the users will like it. It is not however not always so easy and you have to communicate well about it, especially if you follow an Agile approach and are looking for instant and valuable feedback from your demo. In this article, Esena Gusic shares some of the tricks she uses as a product owner when delivering a product demo during the Scrum sprint review. Author: Esena Gusic, Atlantbh, https://www.atlantbh.com/ Working in an Agile team requires delivering frequent product demos to the client. Whether you are a software developer, QA engineer or product owner, this is an inevitable part of the development process. Here at Atlantbh, most projects follow the Scrum methodology using two-week sprints. This means that we deliver demos at least once every two weeks, at the end of each sprint. For most of us, delivering a demo, or any presentation at all, is not a pleasant experience, and that is understandable. Usually there is a number of people, many of them managers, listening to you. Any type of question can be expected and you have the responsibility of presenting the work of the whole Scrum team in the best way possible. Based on my product owner experience, here are some pieces of advice that can help you: A) feel more comfortable while delivering the demo B) get the most out of it 1. Prepare your scenarios well I know this sounds as me reinventing <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/four-steps-for-a-successful-scrum-product-demo/" title="Four Steps for a Successful Scrum Product Demo">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Using Sprint Data to Modify Behavior</title>
		<link>https://www.scrumexpert.com/knowledge/using-sprint-data-to-modify-behavior/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 11 Oct 2016 14:39:28 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[metrics Agile]]></category>
		<category><![CDATA[sprint]]></category>
		<category><![CDATA[sprint reviews]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=3754</guid>

					<description><![CDATA[In an ideal Agile world, the Scrum team can complete all user stories tasks that it planned for the current sprint. The real world is however different. In this article, Scott Lively explains how to use the sprint data to modify the team behavior. In his introduction, Scott Lively explains the feeling of having some user stories not completed during a sprint and the importance of analyzing the sprint data to improve. The article will focus on the percentage of story points coming from new content versus points from carryover content, and the percentage of points added after sprint planning. His analysis of the issues causing the fact of having often carryover user stories at the end of the sprints led Scott Lively to explore the following improvement opportunities: * Writing smaller and better user stories to improve the sprint estimation process * Taking more time to understand the scope of user stories * Cross-training for the Scrum developers so that there are more resources available for all the different activities and technologies involved in software development * Having a mid-sprint assessment meeting to determine of how likely it is that everything planned for the sprint will be completed. This could lead to change the sprint plan and it also gives the Scrum developers another explicit opportunity to help each other. His conclusion is that &#8220;The bottom line is that we need to continue measuring how we do sprint over sprint. Further, we need to be careful about the behaviors <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/using-sprint-data-to-modify-behavior/" title="Using Sprint Data to Modify Behavior">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Scaling the Sprint Review With a Fair</title>
		<link>https://www.scrumexpert.com/knowledge/scaling-the-sprint-review-with-a-fair/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 13 Feb 2013 12:27:02 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[sprint reviews]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1410</guid>

					<description><![CDATA[The main goal of a sprint review in Scrum is to receive feedback on the product that the team has built in the last sprint. How do you do when the product is created by many different teams and there multiple stakeholders who are involved in the Scrum project? In this article, Stephan Kraus explains how to scale the sprint review in Scrum using the fair concept. He bases his article on his own experience working in a project including six different Scrum teams. The initial sprint review were attended by about 30 people, but they noticed that participants weren&#8217;t really active giving feedback and they usually gained only three to five pieces of valuable feedback. In the fair concept, each Scrum team sets up a booth in which the completed user stories and computers on which the software can be tested. Feedback cards and pens are placed beside the notebooks. A ScrumMasters initiates the review and the product owners give a brief presentation to the implemented stories. Then the fair is opened and participants are encouraged to visit the fair&#8217;s booth during 45 minutes, try out the software, and leave comments and suggestions for improving the product on the feedback cards. A lottery on feedback cards is used to encourage the feddback process. As the result, the project now get valuable feedback on the product from 60 to 80 people in just over an hour.]]></description>
		
		
		
			</item>
		<item>
		<title>Take Time to Plan the Scrum Sprint Review</title>
		<link>https://www.scrumexpert.com/knowledge/take-time-to-plan-the-scrum-sprint-review/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Thu, 31 Jan 2013 17:46:03 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[sprint reviews]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1381</guid>

					<description><![CDATA[Positive sprint reviews increase customer confidence in the team and the team’s confidence in itself. If the review goes badly, the trust will degrade, just as we saw in the story. At the same time, don’t forget that the main purpose of the sprint review is not a round of applause for a job well done. The real goal of a sprint review is to stop and ascertain whether the project is on the right track. [&#8230;] Because a positive review experience is so important to the project’s success, take a little time to plan the review so that you feel prepared and confident, especially if you are a new team or a team new to Scrum. It’s perfectly acceptable to use a script or follow the slide outline. In addition, the team should take the time to prepare the demo environment. Set it up so that the customers can put their hands on the new features and experience it first-hand. You’ll find that the team also learns more about how the end user might interact with the product. Allow time not only for the meeting but for some casual chat-time between the customer and the team after the meeting. I allow 30 minutes between the sprint review and the retrospective so that the team and the customer feel free to interact informally. Source: “The Scrum Field Guide : Practical Advice for your First Year”, Mitch Lacey, Addison-Wesley, 364 pages, IBSN 978-0321554154]]></description>
		
		
		
			</item>
		<item>
		<title>Scrum Sprint Reviews Checklist</title>
		<link>https://www.scrumexpert.com/knowledge/scrum-sprint-reviews-checklist/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 15 Aug 2012 10:51:35 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[sprint reviews]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1175</guid>

					<description><![CDATA[In this blog post, Ilan Goldstein shares a list of things to do for successful Scrum sprint reviews, both before and during the meeting. Amongst the important points mentioned, there is the management of expectations, the brief mention of the impediments and improvements of the team. He also discusses the pressure to show &#8220;almost finished&#8221; user stories, how to deal with off topics questions or remarks and how to balance the fun and serious feelings that sprint reviews should convey.]]></description>
		
		
		
			</item>
		<item>
		<title>Improve Your Scrum Meetings</title>
		<link>https://www.scrumexpert.com/knowledge/improve-your-scrum-meetings/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 20 Sep 2011 20:20:59 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[daily stand-up]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[retrospective]]></category>
		<category><![CDATA[sprint reviews]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=722</guid>

					<description><![CDATA[Marc Löffler shares in this blog post 11 hints to improve all the Scrum meetings. He discusses daily stand-up meeting where he suggests to show colleagues what your currently working on instead of just talking about it. He also make proposals to improve the sprint planning, sprint reviews and retrospectives.]]></description>
		
		
		
			</item>
		<item>
		<title>Successful Sprint Reviews: The Greatest Story Never Told</title>
		<link>https://www.scrumexpert.com/knowledge/successful-sprint-reviews-the-greatest-story-never-told/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Thu, 11 Nov 2010 20:37:28 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[sprint reviews]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=253</guid>

					<description><![CDATA[I have observed and participated in a great number of sprint reviews. I’ve seen some quirky things from the Scrum teams as they attempt to demonstrate the working software and artifacts they have produced in the sprint. Most of them squirm and struggle in the art of telling a story. It’s hard to break the habit of thinking only of the technology and step into the world of the person who will live with the system we build. This blog post is about how much more compelling a sprint review would be with a little storytelling.]]></description>
		
		
		
			</item>
	</channel>
</rss>
