<?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>definition of done | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/done/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Mon, 23 Jan 2017 16:20:06 +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>definition of done | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Modifying the Definition of Done</title>
		<link>https://www.scrumexpert.com/knowledge/creating-a-new-definition-of-done/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 23 Jan 2017 16:17:30 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[definition of done]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4030</guid>

					<description><![CDATA[Having a good Definition of Done (DoD) might be one of the most important technical asset of a Scrum team. This makes the difference between delivering at the end of the sprint fully completed business features or half-baked software. In his blog post &#8220;Changing the Definition of Done&#8221;, Ken Rubin discusses the situation where a Scrum team might want to change an existing Definition of Done. Ken Rubin starts with the case of a Scrum team that wanted to remove one check from its Definition of Done, because of technical problems that would have prevented them to deliver any results at the end of the sprint. There might always be some issues that could prevent a Scrum team to respect all the items listed in its Definition of Done. Thus the team could be catch the bad habit of taking shortcuts every time it meet a difficulty and Ken Rubin is against weakening the DoD during the sprint. If the issue isn&#8217;t considered a major one, you can always do a sprint review, but you have to fully inform the stakeholder of the items are not fully &#8220;done&#8221;. There is however no problems to make the DoD stronger if the team can do it without jeopardizing the delivery of software. In all cases, Ken Rubin recommends to change to the Definition of Done between the Scrum sprints. His conclusion is that &#8220;The definition of done is an important list of criterion that a Scrum team uses to determine if the <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/creating-a-new-definition-of-done/" title="Modifying the Definition of Done">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Working as a UX Professional in a Scrum Teams</title>
		<link>https://www.scrumexpert.com/knowledge/working-as-a-ux-professional-in-a-scrum-teams/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 18 Sep 2013 15:41:29 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[definition of done]]></category>
		<category><![CDATA[scrum team]]></category>
		<category><![CDATA[user experience]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1640</guid>

					<description><![CDATA[The Scrum approach recommends to deliver software incrementally in small iterations. This seems to be always an issue with activities that require a global view on the developed application like the software architecture or the user interface. In this blog post, Aviva Rosenstein, who manages user research for Salesforce, shares here experience about integrating user experience (UX) design into the Scrum development process. UX often suffer from a lack of consideration from other roles in the Scrum team. Here are some of her recommendations for UX professionals: * Be transparent about the UX process to create trust in the Scrum team * Participate actively in the Scrum meeting, even if your time is share across multiple teams * Add meetings specifically devoted to the coordination of UX activities * Clarify the definition of Done to include UX criteria * Include UX goals and needs in sprint retrospectives Her conclusion is that &#8220;for Scrum and Agile to live up to its full potential, it must address the needs of all team contributors, not just software developers. Giving support and trust to UX contributors will help motivate them to do their best work and leverage more of their skills in the pursuit of excellence.&#8221; Read the complete blog post on http://boxesandarrows.com/the-ux-professionals-guide-to-working-with-agile-scrum-teams/]]></description>
		
		
		
			</item>
		<item>
		<title>The Implications of Having a Definition of Done on Fixed-priced Contracts</title>
		<link>https://www.scrumexpert.com/knowledge/the-implications-of-having-a-definition-of-done-on-fixed-priced-contracts/</link>
					<comments>https://www.scrumexpert.com/knowledge/the-implications-of-having-a-definition-of-done-on-fixed-priced-contracts/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 29 Apr 2013 15:07:34 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[definition of done]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1474</guid>

					<description><![CDATA[The Definition of Done is an agreement between the Scrum team and the product owner on a minimum quality barrier for the product that’s being built. Establishing a minimum quality barrier has much wider implications than just better quality product, although that is one outcome of having a Definition of Done. This article is about the impact of a definition of done on the types of contract that Agile teams work with. Author: Kane Mar, Scrum Coach, http://scrumology.com What is a Definition of Done? At its most conceptual level the Definition of Done is an agreement between the product owner and the team about what is meant when someone uses the word done. What this means explicitly is that the PO and the team need to sit down and list all the things that they need to achieve before some body of work (for example, a user story) can be considered done. Let’s take a look as some Definitions of Done so that you have a better understand of what’s required. I found these with a quick Google search, and I’ve included the best examples below. source: http://pollenizer.com/definitions-done-and-ready J’Roos Flickr photostream: http://www.flickr.com/photos/jnicho02/2828060974/ source: http://agilecoach.typepad.com/agile-coaching/2010/10/defining-what-done-means.html The Iron Triangle In order to understand the constraints in fixed priced projects, I need to first discuss the Iron Triangle &#8230; a model of constraints often used with traditional project management. We’ll then contrast this with the constraints found in a Scrum project. In the Iron Triangle model of constraints, one side of the triangle <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/the-implications-of-having-a-definition-of-done-on-fixed-priced-contracts/" title="The Implications of Having a Definition of Done on Fixed-priced Contracts">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/the-implications-of-having-a-definition-of-done-on-fixed-priced-contracts/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>7 Reasons Why You Don&#8217;t Get to Done</title>
		<link>https://www.scrumexpert.com/knowledge/7-reasons-why-you-dont-get-to-done/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 23 Oct 2012 21:30:57 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[definition of done]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1264</guid>

					<description><![CDATA[In this article, Faisal Mahmood discusses seven reasons why a Scrum team cannot get to done at the end of a sprint. In Scrum, &#8220;done&#8221; is often defined as producing a potentially shippable product. According to Faisal, the seven reasons that lead Scrum teams not getting to done 1.Team is not cross functional 2.Unclear or absent Definition of Done 3.Technical debt 5.Late integration 6.Change of scope during Sprints 7.Ineffective planning Each reason is then discussed in details in the article.]]></description>
		
		
		
			</item>
		<item>
		<title>Making the Sprint Backlog Ready for Testing</title>
		<link>https://www.scrumexpert.com/knowledge/making-the-sprint-backlog-ready-for-testing/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 02 Oct 2012 17:25:08 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[Agile testing]]></category>
		<category><![CDATA[definition of done]]></category>
		<category><![CDATA[product backlog]]></category>
		<category><![CDATA[sprint]]></category>
		<category><![CDATA[user stories]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1234</guid>

					<description><![CDATA[In his article &#8220;Creating an ATDD Ready Sprint Backlog in Scrum&#8220;, Ralph Jocham discusses the requirements definition in Scrum and how examples allows the team to better understand them. As the backlog is now also expressed in terms of business requirements, each team member can easily focus on the bigger picture during the Scrum stand-up meeting and align with the ‘why’. If you translate the business-facing examples into automated tests, it enables the team to verify during the Sprint that the software increment always meets the evolving requirements towards the Definition of Done and the overall goal. In his proposed approach, a set of acceptance criteria are defined for all the user stories of the product backlog that are included in the sprint backlog. One or more examples are specified for the acceptance criteria. For each example. an acceptance test is written which will fail as the business functionality has not been programmed yet. Then the functionality is coded using a TDD approach. When the test of the example passes and turns green, it means that all unit tests are passing and the acceptance test is working according to the example. This approach seems initially very time consuming, especially for developers not well versed in writing tests first. It is however the basis for a long time sustainable high product development velocity. It allows for fast regression testing which is mandatory when throughput and quality are important.]]></description>
		
		
		
			</item>
		<item>
		<title>Moving a Backlog Item to Done</title>
		<link>https://www.scrumexpert.com/knowledge/moving-a-backlog-item-to-done/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 16 May 2012 16:59:55 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[definition of done]]></category>
		<category><![CDATA[product backlog]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1076</guid>

					<description><![CDATA[This article discusses the the role of the Product Owner in moving a backlog item to done. It explores how to achieve the productivity benefits of an up-front enabling specification, given the reality that Scrum is an empirical framework in which emergent understanding of the story under development is inherent. &#8220;Done&#8221; is not some arbitrary state of a backlog item. When an item is done, users can take advantage of the new functionality and give meaningful user feedback. The article lists some common issues with software delivery: annoying user interface, busy Product Owner, or suboptimal functionality. It then discusses the concept of &#8220;enabling specification&#8221; and its implementation in an empirical approach like Scrum.]]></description>
		
		
		
			</item>
		<item>
		<title>A Thinking Grid for a Definition of Done</title>
		<link>https://www.scrumexpert.com/knowledge/a-thinking-grid-for-a-definition-of-done/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Fri, 14 Jan 2011 18:04:46 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[definition of done]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=377</guid>

					<description><![CDATA[This blog post contains an interesting grid that help you analyze every aspect of your scrum project if you want to declare a sprint &#8220;done&#8221;.]]></description>
		
		
		
			</item>
	</channel>
</rss>
