<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Artifact on Engineering as a Leadership System</title>
		<link>https://engineering.hinshelwood.com/concepts/artifact/</link>
		<description>Recent content in Artifact on Engineering as a Leadership System</description>
		<generator>Hugo</generator>
		<language>en</language>
		
		
		
		
			<lastBuildDate>Tue, 16 Jun 2026 17:40:35 +0000</lastBuildDate>
		
			<atom:link href="https://engineering.hinshelwood.com/concepts/artifact/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>The Definition of Done is a Commitment to Quality</title>
				<link>https://engineering.hinshelwood.com/articles/the-definition-of-done-is-a-commitment-to-quality/</link>
				<pubDate>Mon, 28 Jul 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/articles/the-definition-of-done-is-a-commitment-to-quality/</guid>
				<description>A clear, shared Definition of Done is essential for delivering quality, releasable software in Scrum and aligns teams on what “complete” means. It ensures transparency, predictability, and accountability, protects your product’s reputation, and must be created, automated, and regularly improved by all teams working on a product. Development managers should prioritise running DoD workshops, making standards visible, automating checks, and reviewing the DoD every sprint to maintain quality and reduce risk.</description>
			</item>
			<item>
				<title>Stop Paying the Hidden Costs of Weak Delivery: Why a Strong Definition of Done Transforms Your Team’s Results</title>
				<link>https://engineering.hinshelwood.com/videos/stop-paying-the-hidden-costs-of-weak-delivery-why-a-strong-definition-of-done-transforms-your-team-s-results/</link>
				<pubDate>Wed, 21 May 2025 06:00:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/stop-paying-the-hidden-costs-of-weak-delivery-why-a-strong-definition-of-done-transforms-your-team-s-results/</guid>
				<description>Cutting corners on quality and having a weak definition of done leads to hidden costs like rework, production risks, and lost trust. A clear, shared, and enforceable definition of done ensures every increment is truly usable, reliable, and aligned with business goals. Make your definition of done visible, evidence-based, and strictly enforced to improve delivery outcomes and build stakeholder confidence.</description>
			</item>
			<item>
				<title>Scrum Teams don’t set the bar for quality, they meet it</title>
				<link>https://engineering.hinshelwood.com/signals/scrum-teams-don-t-set-the-bar-for-quality-they-meet-it/</link>
				<pubDate>Thu, 03 Apr 2025 15:30:01 +0100</pubDate>
				<guid>https://engineering.hinshelwood.com/signals/scrum-teams-don-t-set-the-bar-for-quality-they-meet-it/</guid>
				<description>Scrum teams are responsible for meeting, not setting, the quality standard defined by the Definition of Done, which should be a strict, non-negotiable measure of what is releasable. Weakening or fluctuating the DoD increases risk and technical debt, undermining quality and predictability. Development managers should ensure their teams consistently strengthen the DoD over time rather than lowering it to deliver more features.</description>
			</item>
			<item>
				<title>Definition of Done - Objective vs Subjective</title>
				<link>https://engineering.hinshelwood.com/articles/definition-of-done-objective-vs-subjective/</link>
				<pubDate>Fri, 03 Jan 2025 00:00:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/articles/definition-of-done-objective-vs-subjective/</guid>
				<description>The Definition of Done (DoD) in Scrum is an objective, measurable checklist that sets the minimum quality standard for every product increment, distinct from the more subjective Product and Sprint Goals. Teams should ensure their DoD is clear, comprehensive, regularly reviewed, and as automated as possible, avoiding subjective approval steps. Development managers should treat the DoD as a non-negotiable baseline for quality, not a ceiling, and keep it updated to reflect evolving standards and business needs.</description>
			</item>
			<item>
				<title>Why Your Definition of Done Is the Secret Weapon Your Team Needs to Win</title>
				<link>https://engineering.hinshelwood.com/videos/why-your-definition-of-done-is-the-secret-weapon-your-team-needs-to-win/</link>
				<pubDate>Wed, 16 Jul 2025 06:45:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/why-your-definition-of-done-is-the-secret-weapon-your-team-needs-to-win/</guid>
				<description>Many teams struggle not with building software but with finishing it in a way that delivers real business value. A clear, evolving definition of done protects revenue, boosts customer satisfaction, reduces rework, and builds trust by ensuring work is truly complete and valuable. Make your definition of done visible, review it regularly with the whole team, and connect it to real outcomes to turn it into a competitive advantage.</description>
			</item>
			<item>
				<title>Acceptance Criteria vs Definition of Done: Why Getting This Right Builds Trust and Delivers Quality Faster</title>
				<link>https://engineering.hinshelwood.com/videos/acceptance-criteria-vs-definition-of-done-why-getting-this-right-builds-trust-and-delivers-quality-faster/</link>
				<pubDate>Wed, 02 Jul 2025 06:45:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/acceptance-criteria-vs-definition-of-done-why-getting-this-right-builds-trust-and-delivers-quality-faster/</guid>
				<description>Acceptance criteria specify what each backlog item must do, while the definition of done sets the minimum quality standards for all work. Confusing the two leads to missed requirements, technical debt, and loss of trust. Make both explicit and review them regularly to ensure faster delivery and consistent quality.</description>
			</item>
			<item>
				<title>Why Your Definition of “Done” Is Holding Back Quality, Agility, and Trust, And How to Raise the Bar</title>
				<link>https://engineering.hinshelwood.com/videos/why-your-definition-of-done-is-holding-back-quality-agility-and-trust-and-how-to-raise-the-bar/</link>
				<pubDate>Wed, 09 Jul 2025 06:45:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/why-your-definition-of-done-is-holding-back-quality-agility-and-trust-and-how-to-raise-the-bar/</guid>
				<description>Treating “done” as a vague checklist limits quality, agility, and stakeholder trust; instead, teams should define “done” as delivering thoroughly tested, production-ready, and valuable increments that work in the real world. Clear, objective standards for “done” reduce defects, speed up learning, and build confidence with stakeholders. Development managers should work with their teams to set and uphold a robust definition of “done” to drive better outcomes and long-term success.</description>
			</item>
			<item>
				<title>Can the Definition of Done change per Sprint?</title>
				<link>https://engineering.hinshelwood.com/articles/can-the-definition-of-done-change-per-sprint/</link>
				<pubDate>Mon, 14 Oct 2019 13:55:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/articles/can-the-definition-of-done-change-per-sprint/</guid>
				<description>The Definition of Done can be improved each Sprint to raise quality but should never be changed to lower standards or to vary by backlog item, as this undermines transparency and product value. Consistency in the Definition of Done ensures everyone understands what a usable increment means and supports reliable delivery. Development managers should encourage teams to strengthen the Definition of Done over time, aiming for a shippable product each Sprint.</description>
			</item>
			<item>
				<title>Mastering Scrum: Key Insights on Definition of Done, Spikes, and Managing Ad Hoc Work</title>
				<link>https://engineering.hinshelwood.com/videos/mastering-scrum-key-insights-on-definition-of-done-spikes-and-managing-ad-hoc-work/</link>
				<pubDate>Thu, 04 Jun 2020 05:33:42 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/mastering-scrum-key-insights-on-definition-of-done-spikes-and-managing-ad-hoc-work/</guid>
				<description>Focus on team productivity rather than just feature count, and ensure everyone understands the difference between Definition of Done, which sets quality standards, and acceptance criteria, which specify requirements for each item. Use backlog refinement to address unknowns instead of relying on spikes, and plan sprint capacity to accommodate some ad hoc work while maintaining transparency and continuous improvement. Review your team’s approach to these areas to improve delivery and reduce disruptions.</description>
			</item>
			<item>
				<title>Getting started with a Definition of Done (DoD)</title>
				<link>https://engineering.hinshelwood.com/articles/getting-started-with-a-definition-of-done-dod/</link>
				<pubDate>Mon, 14 Dec 2020 13:03:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/articles/getting-started-with-a-definition-of-done-dod/</guid>
				<description>A clear Definition of Done (DoD) is essential for ensuring software quality and predictable delivery, as it sets shared criteria for what &amp;ldquo;done&amp;rdquo; means for every increment. Involve the whole Scrum Team and relevant experts to create a short, measurable checklist that covers code quality, testing, security, and usability, and review it regularly to keep raising the quality bar. Before starting sprints, make sure your current increment meets the DoD, and continuously improve both your software and your DoD to maintain a working, shippable product.</description>
			</item>
			<item>
				<title>Unlocking Success in Agile: Why Your Definition of Done is Essential for Quality Delivery</title>
				<link>https://engineering.hinshelwood.com/videos/unlocking-success-in-agile-why-your-definition-of-done-is-essential-for-quality-delivery/</link>
				<pubDate>Mon, 13 Nov 2023 06:56:47 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/unlocking-success-in-agile-why-your-definition-of-done-is-essential-for-quality-delivery/</guid>
				<description>A clear and shared Definition of Done is essential for delivering quality products in Agile and Scrum, as it sets the standard for what is considered complete and ensures transparency across the team. Without it, teams risk miscommunication, unfinished work, and features that do not meet user needs. Development managers should regularly review and reinforce the Definition of Done with their teams to improve quality and reduce risk.</description>
			</item>
			<item>
				<title>Nexus Guide</title>
				<link>https://engineering.hinshelwood.com/guides/nexus-guide/</link>
				<pubDate>Tue, 17 Sep 2024 00:00:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/guides/nexus-guide/</guid>
				<description>Explains the Nexus framework for scaling Scrum with multiple teams, detailing roles, events, and artefacts to coordinate product delivery and manage cross-team dependencies.</description>
			</item>
			<item>
				<title>Sculpting the Product Backlog: A Delicate Balance Between Lean Inventory and Future Readiness</title>
				<link>https://engineering.hinshelwood.com/articles/sculpting-the-product-backlog-a-delicate-balance-between-lean-inventory-and-future-readiness/</link>
				<pubDate>Thu, 24 Aug 2023 09:00:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/articles/sculpting-the-product-backlog-a-delicate-balance-between-lean-inventory-and-future-readiness/</guid>
				<description>Keep your product backlog minimal but sufficient, ensuring it is clear and transparent for all stakeholders while also considering future needs to avoid surprises. Regularly review and reflect on completed work and unexpected issues to refine your backlog and adapt to changing circumstances. Aim for a balance that supports both current priorities and readiness for what lies ahead.</description>
			</item>
			<item>
				<title>Mastering Product Backlog Management: Essential Skills for Product Owners</title>
				<link>https://engineering.hinshelwood.com/videos/mastering-product-backlog-management-essential-skills-for-product-owners/</link>
				<pubDate>Mon, 18 Dec 2023 07:00:15 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/mastering-product-backlog-management-essential-skills-for-product-owners/</guid>
				<description>Effective product backlog management is critical for delivering value, and product owners remain accountable even when delegating tasks. Focus on managing risk, maximizing value, sizing items for quick delivery, and embracing learning through iteration; regular refinement and clear communication with the team and stakeholders are essential. Review your backlog often, break down large or risky items, and seek help if needed to ensure your team delivers the right outcomes efficiently.</description>
			</item>
			<item>
				<title>Rethinking Product Backlog: Navigating Through the Weeds of Complexity</title>
				<link>https://engineering.hinshelwood.com/articles/rethinking-product-backlog-navigating-through-the-weeds-of-complexity/</link>
				<pubDate>Thu, 17 Aug 2023 09:00:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/articles/rethinking-product-backlog-navigating-through-the-weeds-of-complexity/</guid>
				<description>Relying on rigid hierarchies in the Product Backlog can hinder transparency and adaptability in complex product development. Instead, focus on a flat backlog that highlights valuable, deliverable items, supports team autonomy, and leverages emergent practices over fixed best practices. Empower your teams to structure the backlog in ways that foster learning, innovation, and resilience in changing environments.</description>
			</item>
			<item>
				<title>Unlocking Agile Success: Your Guide to the Professional Scrum Foundations Class and PSM I Assessment</title>
				<link>https://engineering.hinshelwood.com/videos/unlocking-agile-success-your-guide-to-the-professional-scrum-foundations-class-and-psm-i-assessment/</link>
				<pubDate>Thu, 28 May 2020 05:34:33 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/unlocking-agile-success-your-guide-to-the-professional-scrum-foundations-class-and-psm-i-assessment/</guid>
				<description>The Professional Scrum Foundations class offers hands-on, team-based learning to build practical Scrum skills and prepare for the PSM I assessment, with a focus on clear roles, transparency, and empirical process control. Participants who take the assessment soon after the class and use provided resources are more likely to succeed. Investing in this training can improve team collaboration and Agile adoption across your organisation.</description>
			</item>
			<item>
				<title>Navigating the Future with a Fine-Tuned Product Backlog</title>
				<link>https://engineering.hinshelwood.com/articles/navigating-the-future-with-a-fine-tuned-product-backlog/</link>
				<pubDate>Thu, 10 Aug 2023 09:00:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/articles/navigating-the-future-with-a-fine-tuned-product-backlog/</guid>
				<description>A well-ordered and regularly refined Product Backlog is essential for guiding teams toward delivering customer value, as it ensures everyone understands priorities and next steps. Key practices include clear articulation, ongoing refinement, and sizing of backlog items, which help teams focus on the most valuable work and align with strategic goals. Development managers should prioritize maintaining a transparent and evolving backlog to support effective planning and value delivery.</description>
			</item>
			<item>
				<title>What Does a Poor Product Backlog Look Like?</title>
				<link>https://engineering.hinshelwood.com/videos/what-does-a-poor-product-backlog-look-like/</link>
				<pubDate>Mon, 19 Jun 2023 13:01:31 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/what-does-a-poor-product-backlog-look-like/</guid>
				<description>A poor product backlog is disorganised, lacks clear priorities, and confuses both teams and stakeholders. A strong backlog is clearly ordered and understood by everyone, aligning team efforts with business goals. Review your backlog regularly to ensure clarity and shared understanding across your team.</description>
			</item>
			<item>
				<title>The Definition of Done: Ensuring Quality without Compromising Value</title>
				<link>https://engineering.hinshelwood.com/articles/the-definition-of-done-ensuring-quality-without-compromising-value/</link>
				<pubDate>Wed, 27 Sep 2023 09:59:46 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/articles/the-definition-of-done-ensuring-quality-without-compromising-value/</guid>
				<description>The Definition of Done (DoD) ensures every release meets clear quality standards, while acceptance criteria define specific content requirements. Mixing acceptance criteria into the DoD can undermine transparency and adaptability, but consistently required quality measures should be added to the DoD itself. Review your acceptance criteria regularly and only update the DoD if it preserves both clarity and flexibility in your team&amp;rsquo;s delivery.</description>
			</item>
			<item>
				<title>What is a product backlog?</title>
				<link>https://engineering.hinshelwood.com/videos/what-is-a-product-backlog/</link>
				<pubDate>Thu, 18 May 2023 07:00:16 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/what-is-a-product-backlog/</guid>
				<description>A product backlog is a prioritized list of features or improvements that guides the development team and fosters collaboration. It should be flexible, clearly understood by everyone involved, and regularly pruned to stay lean and effective. Development managers should ensure their teams maintain a focused and well-understood backlog to maximize productivity and alignment.</description>
			</item>
			<item>
				<title>A bloated backlog is not a sign of good product management</title>
				<link>https://engineering.hinshelwood.com/signals/a-bloated-backlog-is-not-a-sign-of-good-product-management/</link>
				<pubDate>Thu, 10 Apr 2025 15:30:07 +0100</pubDate>
				<guid>https://engineering.hinshelwood.com/signals/a-bloated-backlog-is-not-a-sign-of-good-product-management/</guid>
				<description>A backlog packed with every idea signals indecision, not good product management. Overloaded backlogs make it hard to prioritize, confuse stakeholders, and slow teams down. Keep your backlog focused on the most valuable upcoming work and regularly remove items your team cannot realistically address.</description>
			</item>
			<item>
				<title>The Importance of Product Backlog Management in Today&#39;s Agile Landscape</title>
				<link>https://engineering.hinshelwood.com/videos/the-importance-of-product-backlog-management-in-today&#39;s-agile-landscape/</link>
				<pubDate>Fri, 01 Dec 2023 07:00:11 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/the-importance-of-product-backlog-management-in-today&#39;s-agile-landscape/</guid>
				<description>Effective product backlog management is essential for team focus, stakeholder alignment, and delivering real value, yet many organizations neglect it, leading to confusion and wasted effort. Key issues include oversized or outdated backlogs, lack of regular refinement, insufficient detail, and poor stakeholder involvement. To improve, keep the backlog lean, refine it regularly with the whole team, ensure transparency and clarity, and use data to guide priorities; making this a priority will boost team performance and stakeholder satisfaction.</description>
			</item>
			<item>
				<title>What is a Sprint Backlog?</title>
				<link>https://engineering.hinshelwood.com/videos/what-is-a-sprint-backlog/</link>
				<pubDate>Mon, 29 May 2023 12:01:04 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/what-is-a-sprint-backlog/</guid>
				<description>The Sprint Backlog is a combination of the Sprint Goal, selected tasks, and a clear plan for achieving them, providing transparency on current work and progress. It should balance goal-driven work with essential tasks like bug fixes, remain flexible to adapt to new needs during the Sprint, and set teams up for achievable success. Development managers should ensure Sprint Goals are realistic and use the Sprint Backlog to maintain focus while staying adaptable.</description>
			</item>
			<item>
				<title>The Product Goal is a commitment for the Product Backlog</title>
				<link>https://engineering.hinshelwood.com/articles/the-product-goal-is-a-commitment-for-the-product-backlog/</link>
				<pubDate>Mon, 23 Nov 2020 14:01:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/articles/the-product-goal-is-a-commitment-for-the-product-backlog/</guid>
				<description>The Product Goal is a clear, measurable long-term objective in the Product Backlog that guides the Scrum Team’s focus and progress. It should be understood by everyone involved, align Sprint Goals, and can be changed if it no longer delivers value. Development managers should ensure their teams have a well-defined Product Goal to drive alignment and transparency.</description>
			</item>
			<item>
				<title>Why &#39;Definition of Done&#39; is Crucial for Success in Scrum</title>
				<link>https://engineering.hinshelwood.com/videos/why-&#39;definition-of-done&#39;-is-crucial-for-success-in-scrum/</link>
				<pubDate>Tue, 14 Nov 2023 07:00:30 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/videos/why-&#39;definition-of-done&#39;-is-crucial-for-success-in-scrum/</guid>
				<description>The Definition of Done sets clear quality standards for all work, ensuring every deliverable meets your organization&amp;rsquo;s expectations regardless of the specific feature or project. It aligns teams, reduces defects, and protects your brand by making sure nothing is released before it is truly ready. Regularly review and adapt your Definition of Done with your team to maintain high quality and customer satisfaction.</description>
			</item>
			<item>
				<title>Rethinking &#39;User Stories&#39;: A Call for Clarity in Product Backlog Management</title>
				<link>https://engineering.hinshelwood.com/articles/rethinking-&#39;user-stories&#39;-a-call-for-clarity-in-product-backlog-management/</link>
				<pubDate>Thu, 31 Aug 2023 13:00:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/articles/rethinking-&#39;user-stories&#39;-a-call-for-clarity-in-product-backlog-management/</guid>
				<description>The author argues that using the term &amp;ldquo;User Stories&amp;rdquo; for all work items leads to confusion and unnecessary complexity, as not all tasks fit this format. Switching to a more generic term like &amp;ldquo;Product Backlog Item&amp;rdquo; allows teams to describe work more clearly and flexibly, improving communication and transparency. Development managers should consider updating their backlog terminology to better reflect the true nature of their work and support more effective product development.</description>
			</item>
			<item>
				<title>Increment</title>
				<link>https://engineering.hinshelwood.com/tags/increment/</link>
				<pubDate>Mon, 05 May 2025 10:17:24 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/tags/increment/</guid>
				<description>Increment refers to the tangible, usable output produced at the end of each iteration, particularly within frameworks like Scrum and Agile. It encapsulates the totality of completed work during a Sprint, ensuring that the product remains potentially shippable and consistently adds measurable value. As a core artifact in Scrum, the Increment embodies the principle of delivering working software incrementally, which facilitates timely feedback, iterative improvements, and mitigates the risks associated with large-scale releases. Its significance lies in the transparency it provides, allowing teams and stakeholders to assess progress clearly, thereby fostering collaboration and alignment. In Agile environments, the Increment serves as a foundation for adaptation, enabling teams to refine their strategies based on feedback and respond effectively to evolving requirements. By prioritising the delivery of increments, organisations can enhance workflows, promote continuous improvement, and ensure that products develop in alignment with customer needs. This focus on delivering working software helps minimise technical debt and prevents over-engineering, aligning development efforts more closely with business objectives. Ultimately, the Increment delivers the concrete, inspectable output that informs decision-making and enhances collaboration, making it a vital component of Agile and Scrum practices.</description>
			</item>
			<item>
				<title>Product Backlog</title>
				<link>https://engineering.hinshelwood.com/tags/product-backlog/</link>
				<pubDate>Mon, 05 May 2025 10:17:24 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/tags/product-backlog/</guid>
				<description>The Product Backlog is a dynamic and prioritised list of work items that acts as the definitive source for what needs to be accomplished in order to deliver a product. It includes features, enhancements, bug fixes, and technical tasks, providing teams with a clear understanding of their objectives. This concept is vital as it allows teams to deliver value in a predictable and sustainable manner by offering transparency regarding priorities and progress. Effective management of the backlog encourages collaboration among stakeholders and enables continuous refinement based on feedback and shifting market conditions. It empowers teams to make informed decisions about their next steps, aligning their work with strategic goals and customer needs. The Product Backlog is more than just a to-do list; it is a living artefact that captures the evolving understanding of the product and its context, promoting a culture of continuous improvement and adaptability. By maintaining a well-structured backlog, organisations can enhance agility, minimise waste, and optimise resource allocation, leading to more successful product outcomes. This systematic approach to backlog management supports long-term planning while remaining flexible enough to address new insights and challenges as they emerge. Ultimately, the Product Backlog is foundational to effective Agile practices, ensuring that teams focus on delivering high-quality, valuable products that meet user expectations and contribute to business success.</description>
			</item>
			<item>
				<title>Definition of Done</title>
				<link>https://engineering.hinshelwood.com/tags/definition-of-done/</link>
				<pubDate>Mon, 05 May 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/tags/definition-of-done/</guid>
				<description>The Definition of Done (DoD) is a critical framework that establishes a shared understanding of what constitutes a completed and releasable product increment within agile and DevOps environments. Originating from the need for clarity in product development, the DoD serves as an organisational standard that all teams must adhere to, ensuring that every increment meets minimum quality criteria before it can be considered complete. This framework is vital for fostering transparency and consistency across teams, enabling empirical decision-making based on real-world feedback. By defining specific criteria, such as deployment in production, telemetry collection, and validation of initial hypotheses, the DoD helps mitigate risks associated with incomplete or subpar work, thereby reducing technical debt and enhancing the overall quality of deliverables. Furthermore, it facilitates faster feedback loops and iterative learning, allowing teams to adapt their processes based on actual performance data. The DoD not only clarifies expectations for stakeholders but also protects the integrity of the product, ensuring that increments are valuable, verifiable, and ready for real-world use. In essence, the Definition of Done is foundational to maintaining high standards in product development, promoting alignment among teams, and ultimately driving successful outcomes in organisational design and delivery.</description>
			</item>
			<item>
				<title>Definition of Workflow</title>
				<link>https://engineering.hinshelwood.com/tags/definition-of-workflow/</link>
				<pubDate>Mon, 05 May 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/tags/definition-of-workflow/</guid>
				<description>The Definition of Workflow in the context of Kanban is a dynamic and explicit model that outlines how work progresses through a value stream, making the flow of work visible and understandable. Rather than being a fixed checklist, it consists of clear agreements and policies that determine how work is selected, initiated, managed, and completed. Key elements include entry criteria, which specify when work is ready to begin; limits on work in progress, which help manage capacity and focus; and exit policies, which define what it means for work to be considered finished at each stage. This approach is not intended for micromanagement but to enhance the transparency and legibility of the system, enabling teams to inspect and continuously improve their processes. In Kanban, the Definition of Workflow is central to making work explicit and fostering a culture of ongoing refinement. While Scrum does not formally define a Definition of Workflow, it incorporates related concepts such as the Definition of Done and encourages teams to visualise their work. Understanding and applying a Definition of Workflow is valuable in agile, DevOps, and product development environments because it clarifies expectations, supports collaboration, and provides a foundation for process improvement and adaptability.</description>
			</item>
			<item>
				<title>Artifact</title>
				<link>https://engineering.hinshelwood.com/concepts/artifact/</link>
				<pubDate>Fri, 21 Mar 2025 13:59:46 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/concepts/artifact/</guid>
				<description>An artifact is a formal, inspectable output that signifies work and progress within a delivery system, particularly in Agile, Lean, and DevOps methodologies. These artifacts, which include the Product Backlog, Sprint Backlog, and Increment in Scrum, are essential for fostering a shared understanding among teams and stakeholders regarding the status of work, what has been completed, and what remains to be done. They are not merely tools or documents; rather, they are defined constructs that promote transparency, inspection, and adaptation. Artifacts play a crucial role in empirical decision-making by allowing teams to assess the current state of work, identify potential risks, and adjust their strategies accordingly. In Kanban and DevOps, similar constructs such as visual work boards and deployment pipelines serve as artifacts that reveal delivery progress and system behaviour. By actively facilitating delivery governance, artifacts enhance alignment, support evidence-based forecasting, and build trust between stakeholders and teams through the visibility of progress and value delivery. Their effective use is vital for successful product development and organisational design, as they contribute to a culture of continuous improvement and responsiveness to change.</description>
			</item>
			<item>
				<title>Working Software</title>
				<link>https://engineering.hinshelwood.com/tags/working-software/</link>
				<pubDate>Tue, 11 Feb 2025 10:17:24 +0000</pubDate>
				<guid>https://engineering.hinshelwood.com/tags/working-software/</guid>
				<description>Working Software is a fundamental artifact in Agile, Scrum, and Lean frameworks, serving as the tangible output of a team&amp;rsquo;s efforts throughout the development process. It emerges from iterative development cycles and acts as a demonstration of progress and value delivery. In Scrum, working software is the primary success metric for each Sprint, encapsulated in the Increment artifact, which is subject to inspection and adaptation based on stakeholder feedback. The Definition of Done ensures that the software meets established quality criteria, making it valuable and ready for release. The importance of working software lies in its ability to provide a concrete measure of progress, aligning teams and stakeholders around completed work and remaining tasks. It transcends mere code, representing deliverables that address real-world needs and customer expectations, thereby maintaining a focus on value delivery. In agile methodologies, the emphasis on working software fosters continuous feedback and improvement, enabling teams to release increments iteratively and adapt to evolving requirements. This focus enhances collaboration, increases transparency, and drives ongoing improvement within organisations. Ultimately, working software is not solely about technical execution; it is about consistently delivering value, responding to customer needs, and ensuring long-term sustainability, thereby contributing to customer satisfaction, innovation, and overall business success.</description>
			</item>
	</channel>
</rss>
