TL; DR: The Definition of Done: Business Agility & Technical Excellence
Most of the time, stakeholders are not interested in how we solve their problems as long as we ethically play by the rules. Instead, they are interested in the regular delivery of valuable Increments as these pave the road to business agility. However, there is no business agility without technical excellence, which brings us to today’s topic: the importance of an actionable Definition of Done.
Learn more about twelve success principles of employing such a Definition of Done as a Scrum team to help your organization become agile.
When is the time to look beyond Scrum? After all, many things—ideas, practices, mantras, etc.—outlive their utility sooner or later; why would Scrum be an exception? Moreover, we are not getting paid to practice Scrum but solve our customers’ problems within the given constraints while contributing to the sustainability of our organization. Scrum is a tool, a helpful practice but neither a religion nor a philosophy. Which brings us back to the original question: Is there a moment when a Scrum team should stop using Scrum?
In Scrum, the Sprint Goal serves as the spotlight that provides transparency to the Sprint Backlog, as the flag that allows the team to rally, and the one thing that provides focus and cohesion. No Scrum team has ever been able to reap the benefits of the framework to the fullest extent without making the Sprint Goal a cornerstone of its efforts. The following nine Sprint Goal principles point at critical issues any Scrum team needs to consider on its path to excellence.
In its theory section, the Scrum Guide refers to the three elements of empiricism: transparency, inspection, and adaptation. However, a fourth element, foundational to enable empiricism, is hidden in a sentence on Scrum Values. Read on and learn more about the complete picture of Scrum’s empiricism.
What is your take on the Retrospective: A routine exercise at the end of a Sprint, supported by standard operating procedures? Or a critical part of a Scrum team’s journey of continuous improvement? As you may assume, I advocate for the latter. In my experience, Scrum teams start utilizing Retrospectives to their full potential when they embrace a short set of Retrospective first principles, outlining the essence of the Why, the What, and the How.
TL; DR: Product Backlog Refinement First Principles
The Product Backlog refinement is a continuous process to create actionable Product Backlogs, enabling a Scrum Team to run Sprint Plannings at a moment’s notice. Consequently, refinement is about creating alignment among all team members about the Why, the What, the How, and probably even the Who regarding the upcoming work for the Scrum team’s Product Goal. As a result, Product Backlog refinement is a critical success factor as it drastically increases the team’s capability to deliver valuable Increments regularly.
The following 14 first principles describe in broad strokes the foundation of a successful approach to refinement.
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
3rd Party Cookies
This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.
Keeping this cookie enabled helps us to improve our website.
Please enable Strictly Necessary Cookies first so that we can save your preferences!
