Experienced Scrum practitioners often reach a plateau where the mechanics are mastered, but the outcomes still feel constrained and inefficient. If you are comfortable with Scrum and ready to evolve your practice, consider an approach that reframes the Product Backlog and Sprint Planning around value and outcomes rather than stories and estimates.

Agile isn’t one-size-fits-all. **Plan–Do–Inspect–Adapt** (PDIA) is powerful for delivery work, but when the goal is to explore strategy, test hypotheses, or navigate ambiguity, you need a different mindset—**Frame–Learn–Assess–Improve** (FLAI). Here’s why a small shift in language can reshape the way we lead.

This article challenges the conventional view of Scrum as merely a delivery framework and reframes it as a powerful engine for product innovation and evolution. While many teams use Scrum to deliver work more predictably, the real opportunity lies in using it to discover what truly adds value for customers. This blog presents four practical strategies to make Scrum more innovation-focused: 1. Treat releases as experiments to validate assumptions. 2. Release based on value, not just Sprint boundaries. 3. Embrace strategic procrastination to keep backlog items flexible. 4. Refine frequently in small efforts to reduce rework and support adaptability. The conclusion emphasizes that Scrum, when used thoughtfully, enables teams not just to ship features, but to learn, adapt, and deliver meaningful outcomes in dynamic markets.

We are often told that getting to “yes” when asking a question is a powerful negotiation technique. That much is true but asking questions that lead to “no” can really tease out conversations and help to understand why a certain position is held by someone.

MVP has been thrown around so much and for so long that the term’s original power is lost. I propose replacing “minimum viable product” with “minimal inspectable increment.” to clarify the scope, intent, and article. 

During this article, we’ll look at some basics about the Definition of Done (DoD). We’ll explore misunderstandings such as the application of the DoD, ways to use a fully achievable DoD and avoid creating a waterfall approach, when to inspect and adapt the DoD, and an example starting point for your DoD.

If you're planning on taking one of the Scrum.org assessments, here's general hints for multiple choice questions.

Sprint Goals and Product Goals are really tough to grasp an apply. Most people just restate the PBIs as the goal. Here's a checklist to help you make useful Sprint Goals and Product Goals.

Use story points to drive out assumptions, not estimate and forecast. Use flow metrics for that (while ignoring story point values). If you use story points and planning poker for the right thing, they both can be helpful.

Why did the Scrum Guide 2020 add commitments? What is a commitment? Let's look into ths!

One of the primary purposes of a retrospective is to create action items, but it’s not uncommon to come up with action items that aren’t actionable.  They’re aspirational.  This blog gives you some ways to ensure your retrospectives have actionable items.

To meet schedules, deliver valuable products, and exceed your stakeholder’s expectations, you need the ability to flex scope and offer an actual minimum marketable product.  You need to know how to break down your work to be forced by technology or business processes to deliver anything more than the minimum. 

You certainly know that COVID-19 has caused a great deal of loss. We’ve lost lives and have had a tremendous shift in our daily behavior.

A few years ago, I became acquainted with a lady running a charity for a child who was having medical bills pile up. She was holding a charity bazaar to raise money for the child's family.

Can anyone be a Product Owner (PO)? What’s the best position in the company to fill that role? With Scrum you have one and only one Product Owner for a given product...

User stories are business needs, not requirements in the traditional sense. They are oriented toward the user and a business need. The big difference between a user story and other types of requirements is that a story describes a business need, not the system’s functionality.

Do you ever influence or coach people?  How?  Do you use a gut feel approach or do you have coaching patterns that you use?  I have several coaching patterns that I step through when trying to influ

Check out this job advertisement:

Ah, the Daily Scrum, so often misused as an instrument of status (see https://youtu.be/i7_RPceEIYE for a discussion). Often the way the Daily Scrum is conducted lends itself to a report of status.