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.
TL; DR: When Should a Team Stop Using Scrum?
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?
TL; DR: Nine Sprint Goal Principles
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.
TL; DR: Elements of Empiricism
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.
TL; DR: Retrospective First Principles
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.
For classic nerds: “Molon labe (Ancient Greek: μολὼν λαβέ, romanized: molṑn labé), meaning ‘come and take [them][…]’”
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.