<?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>documentation | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/documentation/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Thu, 10 Oct 2024 16:25:38 +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>documentation | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Improving Project Efficiency through Effective Contract Management and Renewal</title>
		<link>https://www.scrumexpert.com/knowledge/improving-project-efficiency-through-effective-contract-management-and-renewal/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 26 Aug 2024 06:47:17 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[documentation]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8017</guid>

					<description><![CDATA[Since Scrum is a project management framework that aims to minimize costs and maximize business value, project managers must continuously look for ways to improve productivity and efficiency. As such, a previous post highlights &#8216;5 Project Management Hacks for Improved Efficiency and Productivity&#8217; while still ensuring the quality of work and project outcomes. Such tips include adopting project management tools to streamline individual and collaborative workflows, setting clear and realistic goals as a yardstick for success, and prioritizing tasks to meet tight deadlines and achieve objectives. On top of these tips, managers and their teams can also handle project scenarios more efficiently through effective contract management and renewal. Below, we discuss the benefits of optimizing contract-related processes and which strategies project managers can employ to ensure timely contract execution and renewal. Benefits of effective contract management Contracts are crucial to outlining the terms of the relationship between project teams and their partners, vendors, and suppliers. Since Scrum teams can also outsource staff to respond more quickly to client requests and stakeholder feedback, well-drafted contracts help formalize outsourced workers&#8217; integration into workflows while also protecting business interests. Therefore, contract management must be undertaken to handle contracts throughout their entire lifecycle, not only during initiation and execution but also during monitoring and renewal to ensure project continuity. Furthermore, contract lifecycle management can address scope creep, which negatively affects over half (52%) of projects, according to a CIO article. Scope creep can hinder project completion and success through uncontrolled growth and delayed timelines, <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/improving-project-efficiency-through-effective-contract-management-and-renewal/" title="Improving Project Efficiency through Effective Contract Management and Renewal">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Spreading Tribal Knowledge in Scrum Teams with History Lines</title>
		<link>https://www.scrumexpert.com/knowledge/spreading-tribal-knowledge-in-scrum-teams-with-history-lines/</link>
					<comments>https://www.scrumexpert.com/knowledge/spreading-tribal-knowledge-in-scrum-teams-with-history-lines/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 22 Jan 2019 09:06:36 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[documentation]]></category>
		<category><![CDATA[scrum team]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=5524</guid>

					<description><![CDATA[Agile and documentation are not two words that are often associated in articles or blog posts. Scrum teams have however to find alternate ways to spread the knowledge among their member. In this article, Viktor Cessan explains how he uses an exercise named History Lines to share knowledge in Agile teams. Author: Viktor Cessan, https://www.viktorcessan.com/ To help teams share and document tribal knowledge I run/facilitate an exercise I call History lines. History Lines is a mix between an exercise called Journey lines and an exercise Johan Strömberg introduced to me. This is used as a part of a larger workshop for strategic visioning where history is a vital part of shaping your future vision In this exercise teams are asked to visualize how different things have changed over time and at the end of the exercise you have helped spread knowledge to everyone in the team, the team has drawn new conclusions about their past, and they’ve documented some parts of their tribal knowledge. I have found History lines useful when: Team composition changes e.g. when merging or splitting teams or when on-boarding several new members in a short period of time Team members have come to rely on specific people for context Bootstrapping new teams Visualize what makes sense for your team Depending on the type of team you are working in e.g. feature team, infrastructure team, component team, or management team, you want to visualize different things. A feature team might find it valuable to plot how customer <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/spreading-tribal-knowledge-in-scrum-teams-with-history-lines/" title="Spreading Tribal Knowledge in Scrum Teams with History Lines">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/spreading-tribal-knowledge-in-scrum-teams-with-history-lines/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>The Goals of Agile Documentation</title>
		<link>https://www.scrumexpert.com/knowledge/goals-agile-documentation/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 20 Aug 2018 15:07:15 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[documentation]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=5262</guid>

					<description><![CDATA[As the Agile Manifesto stated that it prefers &#8220;working software over comprehensive documentation&#8221;, some early Agile adopters jumped to the conclusion that documentation was useless. Thus Scrum software developers should only concentrate in creating working software with code that was the most easier to understand. The Agile Manifesto however also said that there is some value on the left side of the comparison and in her tow blog posts Birgitta Böckeler reminds us that Agile documentation fulfills some important goals. Birgitta Böckeler starts her blog post explaining that there is value in documentation, that there is no fixed rules about how much documentation is enough and finally that documents have different audiences from software developers to final users. Then she follows by listing four goals that documentation can have for Agile and Scrum teams. 1. Creating a shared understanding Some things might seem to be clear in the heads of the members of the Scrum teams but with a slightly different point of view, like the software architecture for instance. Creating a document helps team members to discuss formally the topic and achieve a common understanding. Birgitta Böckeler proposes to create a wall of shared understanding with the main things that Agile members team should agree upon. She provides some tips on how to select the items that should appear on this wall. 2. Expose complexity Even if Agile software developers should strive for simplicity, there are often some points that might require more explanation, like a data migration plan <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/goals-agile-documentation/" title="The Goals of Agile Documentation">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Fostering a Culture of Documentation in Scrum</title>
		<link>https://www.scrumexpert.com/videos/fostering-a-culture-of-documentation-in-scrum/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 04 Dec 2017 14:28:14 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[documentation]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4785</guid>

					<description><![CDATA[Documentation and Agile are two words that are rarely seen together, but documentation is still the most important thing developers continually respond as most affecting their decision making. Frankly caring about documentation shows you care about the developer, whether external or internal. Yet, documentation is constantly pushed to the wayside, aligning that idea with Waterfall and top-down development. How do you then foster a culture that gets your developers excited to create documentation? And as an extension, how do you get your developers excited about pleasing their customers? Start out by automating what you can and then creating a process. Documentation is something that requires discipline. It’s up to your team to identify what interruptions are constantly being pointed to as excuses for not completing the documentation. Then, you can put an investment into your documentation, looking to first solve and reduce those interruptions, making documentation the way you address repeated issues and make your customers more autonomous. Documentation is actually particularly important to the Scrum process, where &#8220;documented&#8221; is part of the definition of &#8220;Done.&#8221; Documentation can also be a good team-building exercise as it invites everyone to take ownership of their own piece. It also keeps everyone cognizant of keeping the code itself simple and self-explanatory. And it&#8217;s especially important for team communication and collaboration as, with microservices, containers and the like, our developers gain autonomy, but there&#8217;s a struggle to work out loud so you know what everyone else is doing. Finally, someone should be in charge <a class="mh-excerpt-more" href="https://www.scrumexpert.com/videos/fostering-a-culture-of-documentation-in-scrum/" title="Fostering a Culture of Documentation in Scrum">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Your Scrum Team Needs to Document More</title>
		<link>https://www.scrumexpert.com/knowledge/your-scrum-team-needs-to-document-more/</link>
					<comments>https://www.scrumexpert.com/knowledge/your-scrum-team-needs-to-document-more/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 28 Oct 2013 16:05:22 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[documentation]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1676</guid>

					<description><![CDATA[One of the major selling points of Scrum to developers is how much less documentation is involved. Developers worked hard to get where they are: a college degree, nights and weekends at home working through books and exercises trying to learn the latest language, and struggling through their first few projects to get something that works into production. They don&#8217;t want to come all that way just to spend most of their day in the word processor. They want to code. Author: Nate McKie, CTO, Asynchrony Inc., www.asynchrony.com When Scrum gives them a taste of what it means to emphasize code over specifications and architectural diagrams, they never want to go back. However, completely giving up on documentation has its own price, and it&#8217;s one that can be avoided without a lot of effort. Agile even de-emphasized documentation in the Manifesto for Agile Software Development: Working software over comprehensive documentation. So is all documentation bad? I think you know the answer. There are many times in the life of a project when a little documentation goes a long way, and development teams should consider that it&#8217;s worth taking a bit of time away from coding to write things down. Here are some examples: Remembering Why You Made Decisions If a project goes on much longer than a few months, there will be times when decisions are made that change the course of the development effort. It may be a decision to use (or explicitly avoid) a particular tool, framework, or <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/your-scrum-team-needs-to-document-more/" title="Your Scrum Team Needs to Document More">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/your-scrum-team-needs-to-document-more/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>No Documentation in Scrum?</title>
		<link>https://www.scrumexpert.com/knowledge/no-documentation-in-scrum/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 14 Feb 2012 15:56:17 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[documentation]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=941</guid>

					<description><![CDATA[During Scrum adoption, people tend to get away from tasks and activities that they don&#8217;t like in traditional projects like documentation or writing proper code comments. In this article, a ScrumMaster shares his experience with a &#8220;no documentation&#8221; approach. He learned the hard way that minimal documentation is better than no documentation in Scrum projects. The team can decide on a case-by-case basis what level of documentation for which components and code logics is needed.]]></description>
		
		
		
			</item>
		<item>
		<title>What Is Agile Documentation?</title>
		<link>https://www.scrumexpert.com/knowledge/what-is-agile-documentation/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 31 Jan 2012 17:12:03 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[documentation]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=903</guid>

					<description><![CDATA[Does the term &#8220;documentation&#8221; have any place in an agile environment? The goal on agile projects is to keep documentation as simple as possible, relying on roadmaps, overviews and concepts rather than enterprise-focused details. But what happens when using an agile approach on more complex projects? For example, what if the team that writes the software is different from the team that must maintain it? Or what if auditors come calling? In these instances, basic agile documentation based on user stories alone may come up short. This article provides insights into how teams can take an agile approach to documentation in more complex environments.]]></description>
		
		
		
			</item>
		<item>
		<title>Agile Architecture</title>
		<link>https://www.scrumexpert.com/knowledge/agile-architecture-2/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 31 Oct 2011 08:52:56 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[documentation]]></category>
		<category><![CDATA[software architecture]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=778</guid>

					<description><![CDATA[Upfront Modeling is fine, documents describing the intended architecture are fine, and so forth. But the architecture, and our learning about it, can improve. Speculative software architecture should be made concrete and not of concrete. Agile architecture comes from the behavior of agile architecting &#8211; hands-on master-programmer architects, a culture of excellence in code, an emphasis on pair-programming coaching for high-quality code/design, agile modeling, design workshops, test-driven development and refactoring, and other hands-on-the-code behaviors. Source: Practices for Scaling Lean &#38; Agile Development &#8211; Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Craig Larman and Bas Vodde, Addison Wesley, ISBN 978-0-321-63640-9]]></description>
		
		
		
			</item>
	</channel>
</rss>
