<?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 | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/sprint/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Mon, 15 Jul 2024 13:24:58 +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 | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>A Definition of Done Checklist for Agile Teams</title>
		<link>https://www.scrumexpert.com/knowledge/a-definition-of-done-checklist-for-agile-teams/</link>
					<comments>https://www.scrumexpert.com/knowledge/a-definition-of-done-checklist-for-agile-teams/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 23 Jan 2024 21:45:23 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[scrum team]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7765</guid>

					<description><![CDATA[The Definition of Done (DoD) is a common understanding within the Scrum team on what it takes to make your software ready to be released. In their book &#8220;Managing the Unmanageable&#8221;, Mickey Mantle and Ron Lichty propose an extensive list of what a Definition of Done should include. You could use do these elements to create your own DoD for your Agile team. The project kickoff is often the right time to get agreement around the question “When is a feature, task, or sprint done? What constitutes ‘done’?” Defining “done” is a joint exercise with the business, the development team, project management, QA, and sometimes others to define when each feature can be declared done. In addition to being coded, will it need Design review Peer review (or pair programming) Code review Unit testing Check-in to source control Commenting in source control Performance testing Refactoring Any changes required to build it communicated to the buildmeister Online help written and integrated Built out of source control Unit tests passed on the source control build Automated regression tests for the integrated application passed on the new source control build Bugs fixed Installation scripts written Tested on multiple platforms, browsers, configurations, etc. Story or use case test plan updated Documentation written Product managers’, product owner’s, and/or customers’ acceptance that it meets expectations Task hours recorded Tasks closed out It’s important for the team to agree to the elements of “done” and agree to deliver them. It’s infrequent that two teams agree on the <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/a-definition-of-done-checklist-for-agile-teams/" title="A Definition of Done Checklist for Agile Teams">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/a-definition-of-done-checklist-for-agile-teams/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Running Scrum Sprints From Mid-week to Mid-week</title>
		<link>https://www.scrumexpert.com/knowledge/scrum-sprints-mid-week-to-mid-week/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Thu, 27 Jul 2023 14:15:01 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7582</guid>

					<description><![CDATA[Figure 3 deliberately shows an iteration running mid-week to mid-week. My experience, and the experience of others assisting teams, is that running iterations mid-week to mid-week is more effective than running them Monday to Friday. Why this should be so is difficult to pin down, but there are several reasons that I believe contribute: The ‘Friday afternoon effect’. If an iteration resets on a Monday, then anyone completing a piece of work on Friday will not be particularly motivated to start another piece of work. In many environments it is common to finish early on Friday, or take a long lunch. If the iteration has several more days to run, there is less incentive to ‘slack off’ on a Friday afternoon. Monday refresh. I believe there is research showing that people are more effective at the start of a new week. I hasten to add I have not read this research myself, which is a little lax of me. Anecdotally many people, if asked, say their most productive day is Tuesday. Assuming there is truth in these tales, it is a good reason to avoid meetings on Monday and Tuesday. Public holidays. In the UK and many other countries many public holidays occur on Mondays. This means that there is more chance of an iteration meeting being disrupted if it is scheduled on a Monday. Personal holidays. Again in the UK and many other countries individuals are more likely to take a Friday or Monday off as a long weekend. <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/scrum-sprints-mid-week-to-mid-week/" title="Running Scrum Sprints From Mid-week to Mid-week">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Improving Scrum Sprints with Kanban</title>
		<link>https://www.scrumexpert.com/knowledge/improving-scrum-sprints-with-kanban/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 05 Jan 2021 17:50:53 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[kanban]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6509</guid>

					<description><![CDATA[Scrum and Kanban are not rivals. If your Scrum Sprints are getting bogged down or missing the mark, combining Scrum with Kanban might be the Agile answer. This article from Kert Peterson provides a comprehensive explanation of how Kanban can improve your Scrum process with Kanban Task Boards, Team Boards, and a better focus on customer needs. The goal of this article is to explore the application of Kanban within a Scrum sprint. It discusses how Scrum can use some aspects of Kanban to improve value creation and more effectively deliver the sprint goals. Many Scrum teams already use a task board similar to Kanban with &#8220;To Do&#8221;, &#8220;Doing&#8221; or &#8220;Done&#8221; columns. The author writes that this task board must be examined and evolved to foster shared ownership and sharpen the team&#8217;s focus on value delivery. Tracking tasks may be interesting and useful to Scrum teams, but they are irrelevant to the customer and the Product Owner. It is therefore recommended visualizing progress at a higher level like the product backlog item or user stories. The second recommendation is to apply the Work in Progress (WiP) limit more globally. Even if Scrum natively limits work-in-progress through the sprint plan, teams are often overcommiting and WIP limits on the appropriate columns will introduce a constraint that will encourage shared ownership of issues. The article also recommends managing the flow, making process policies explicit and implement additional feedback loops besides the daily Scrum meetings and the retrospectives. The conclusion of the article <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/improving-scrum-sprints-with-kanban/" title="Improving Scrum Sprints with Kanban">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Connect Design Sprints and Agile Sprints</title>
		<link>https://www.scrumexpert.com/videos/connect-design-sprints-and-agile-sprints/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 10 Feb 2020 10:27:10 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[sprint]]></category>
		<category><![CDATA[user experience]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6149</guid>

					<description><![CDATA[Design Sprints have changed the way businesses create new products and services. But how do they relate to Agile development sprints? And how can the two be connected so that Scrum teams deliver higher quality products in less time? Video producer: https://www.agileonthebeach.co.uk/]]></description>
		
		
		
			</item>
		<item>
		<title>How to Facilitate a Scrum Sprint Goal Session</title>
		<link>https://www.scrumexpert.com/knowledge/how-to-facilitate-a-scrum-sprint-goal-session/</link>
					<comments>https://www.scrumexpert.com/knowledge/how-to-facilitate-a-scrum-sprint-goal-session/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 01 May 2018 10:09:09 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[people]]></category>
		<category><![CDATA[scrum team]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=5090</guid>

					<description><![CDATA[The Scrum Glossary defines the Sprint Goal as &#8220;a short expression of the purpose of a Sprint, often a business problem that is addressed&#8221;. In this article Özmen Adibelli provides a facilitation meeting structure and some tips on how to facilitate a session about a controversial topic like the Sprint Goal. Author: Özmen Adibelli, ACM, http://www.acm-software.com/en/ The Sprint Goal is tricky concept. Some people think that it is a must. Some think that it is useless. Is there a point somewhere in between? We wanted to figure this out. That is why we gathered with the Scrum Masters in the organization that I help as an Agile Coach. I know that gathering in a room and giving “important” information about Sprint Goal would not work. People have different ideas. Every team has its own conditions and best practices may not work as “plug and play” in a complex environment. So, I wanted to facilitate an interactive Sprint Goal session. A session in which participants don’t want to check their latest Instagram stories. Hopefully, they would leave the room with new ideas to experiment and excitement to apply. Here is my facilitation format: 1. Why are we here? After welcoming participants, I asked why they were in the meeting. Mostly, that is not what people expect. It makes people understand that it is not a listening session. Telling “I want this meeting to be interactive” does not work. Because interactivity is not something you ask for, but it is something you <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/how-to-facilitate-a-scrum-sprint-goal-session/" title="How to Facilitate a Scrum Sprint Goal Session">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/how-to-facilitate-a-scrum-sprint-goal-session/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Google Design Sprint Kit</title>
		<link>https://www.scrumexpert.com/resources/google-design-sprint-kit/</link>
					<comments>https://www.scrumexpert.com/resources/google-design-sprint-kit/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 30 Jan 2018 17:57:57 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Resources]]></category>
		<category><![CDATA[sprint]]></category>
		<category><![CDATA[user experience]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4860</guid>

					<description><![CDATA[The Google design sprint framework is a five-phase framework developed by Google that helps answer critical business questions through rapid prototyping and user testing. The design sprints let teams reach clearly defined goals and deliverables and gain key learnings. According to Google, this process helps spark innovation, encourage user-centered thinking, align teams under a shared vision, and get faster to product launch. Created in 2010, the Google design sprint framework is the result of the study and test of 300 different business strategy, design thinking, and user research methods from places like IDEO and Stanford d.school. Google took the most effective ones and evolved them, arranging them into a framework that supports both divergent thinking (creative brainstorming that results in multiple possible solutions) and convergent thinking (using defined, logical steps to arrive at one solution). The methodology has evolved over time and continues to be refined and tested. The Google design sprint framework website provides different case studies, a step by step guide to planning the design sprint, tools and templates tools to help you run design sprints and a FAQ. In the context of Scrum, this approach could be interesting to explore before you actually launch you project in a process that is often labeled as &#8220;iteration zero&#8221;. Read all the documentation about the Google Design Sprint Kit on https://designsprintkit.withgoogle.com/]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/resources/google-design-sprint-kit/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Why Splitting Unfinished Product Backlog Items is a Bad Idea</title>
		<link>https://www.scrumexpert.com/knowledge/why-splitting-unfinished-product-backlog-items-is-a-bad-idea/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 16 May 2017 08:33:57 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product backlog]]></category>
		<category><![CDATA[product owner]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4413</guid>

					<description><![CDATA[In an ideal Agile world, the Scrum team is always completing all the selected user stories at the end of the sprint. In the real world however, there might be some product backlog items that don&#8217;t have a &#8220;done&#8221; status, but are only partially finished. Should you split them for the next sprint? In this article, Daniel Zacharias gives you four reasons why it is a bad idea to split unfinished product backlog items. Author: Daniel Zacharias, Hexacta, http://www.hexacta.com/ In the Agile world of Scrum, there are two types of product backlog items (PBIs) at the end of a sprint: those that are done – that comply with the Definition of Done or DoD – and those that are not. If we want to be faithful to the methodology, those unfinished PBIs, regardless of their degree of progress, should be returned to the product backlog. (see also: 5 keys you can’t skip on your agile process). Once the unfinished PBI is put back into the product backlog, the product owner must prioritize it again and include it (or not) into the next sprint to finish it. When re-assigned back to a sprint, the amount of story points assigned to this PBI should not change, since the effort to implement it, as a whole, remains the same. However, many of us who work with Scrum have lived through the situation where a sprint has finished and one of its PBIs is incomplete. It’s tempting to split it into two and leave <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/why-splitting-unfinished-product-backlog-items-is-a-bad-idea/" title="Why Splitting Unfinished Product Backlog Items is a Bad Idea">[...]</a>]]></description>
		
		
		
			</item>
		<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>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>RUP Practices That Could Help Scrum</title>
		<link>https://www.scrumexpert.com/knowledge/rup-practices-that-could-help-a-scrum-project/</link>
					<comments>https://www.scrumexpert.com/knowledge/rup-practices-that-could-help-a-scrum-project/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 02 Jul 2013 08:33:07 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1560</guid>

					<description><![CDATA[As there is no all-size fits all software development process, even Scrum practitioners can learn some tricks from Rational Unified Process (RUP) for implementing more effective the customer’s requirements. The iterations from RUP can help stabilize the agile approach and offer increasing predictability of the developed software, future architecture and spent budget while keeping the flexibility toward client’s requests, development team buy-in and involvement, and the incremental delivery of the developed system. We will present in this article the most important features from RUP identified in conjunction with Scrum for a more agile project management style in the benefit of all stakeholders. Author: Adriana Martin Scrum is an agile approach that uses project backlog instead of scope. It allows the backlog to be redefined at the end of each iteration (usually about every 2 weeks) and determines if the entire “traditional” lifecycle fits into one iteration called sprint. The requirements for a particular feature are collected, documented as a user story, then coded, tested and presented for the user review after each iteration RUP is a four-phase process oriented methodology (namely inception, elaboration, construction, and transition) for software development. It is an iterative approach that takes into account the need to accommodate change and adaptability during the development process. It requires a formal definition of scope, and major project milestones are associated with specific dates, subdivides the project lifecycle into phases, which can include iterations. We will present further in detail some of the most important RUP features that could <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/rup-practices-that-could-help-a-scrum-project/" title="RUP Practices That Could Help Scrum">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/rup-practices-that-could-help-a-scrum-project/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
	</channel>
</rss>
