Chuck Suscheck-PST

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. 

If you’ve used agile, you’ve heard of creating the minimum viable product (MVP). MVP has been thrown around so much and for so long that the term’s original power is lost. The original intent is that if you make an MVP, you are making something valuable that your customers can use, albeit without many bells and whistles. Unfortunately, the phrases “minimum viable product” or “minimum valuable product” is open to interpretation, especially when the phrases’ intent isn’t clear. It’s challenging to know when you have the right product increment to deliver to a customer. MVP is interpreted as something whole, usable, and valuable to the customer, emphasizing whole. “Minimum” becomes close to “maximum.” The MVP becomes a point of contention – leaders press to have viable mean more and more functionality, developers use minimum to lessen scope. In many cases, the minimum viable product becomes the first and only release, while any subsequent releases become minor enhancements, or worst yet, patches. The MVP isn’t put into the customers’ hands until many sprints have passed, so very little customer feedback is available as the product evolves. Agile is based on an empirical approach: uncovering knowledge that may not be discoverable or knowable without trying small experiments. It’s a tried-and-true method, applied to all sorts of science, innovative work, and throughout the business world. Agilists use the empirical strategy of plan-do-inspect-adapt. We plan out a small work effort as a hypothesis, prob the validity of the hypothesis by developing an increment of the product, and then inspect our experiment’s results in order to extend or adjust the original hypothesis. How can you get the most valuable results from an experiment? Test the hypothesis (in this case, product increment) in an environment close to the actual situation. Test the developed product increment with your customers who will use the product and review how it is adopted and used. The feedback from those closest and most knowledgeable about the product will produce the best test of your hypothesis. The experiment should be small enough not to cause catastrophic failure and small enough not to introduce many change points. The experiment should be viable in that the customer will encounter and hopefully use the changes. Each deployment should have a way to analyze the experiment’s effect (built-in analytics, customer feedback mechanism, direct observations, and more). Lastly, take the results of the experiment into account going forward. I propose replacing “minimum viable product” with “minimal inspectable increment.” The change may seem small, but it clarifies the scope, intent, and article. Minimum means the smallest amount or quantity required in absolute terms, while minimal refers to being the smallest amount or degree in non-absolute terms. Minimal give you more flexibility to produce something that is not the complete product. “Inspectable” points to the purpose of the product – something that can help guide you to determine if you are building the right thing. The result of a sprint is an increment or product. Replacing “product” with “increment” infers that product development will continue. These changes may seem academic, but words matter, clarity is essential. I’ve seen many agile shops that continue to skirt the intent of agile either through ignorance or to maintain a sense of predictability. Agile is about inspecting and adapting, and you can get the best results if you adopt a more experimental approach. Thanks for reading. I hope this helped.

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.