Product Owners Getting the Attention They Deserve

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.
— “The Scrum Guide”, Ken Schwaber and Jeff Sutherland, November 2017

After a slow start, interest in the Product Owner role in Scrum is gaining momentum. It’s about time given the significant impact this role contributes to value creation! Of course Development Teams and Scrum Masters are important as well. After all, the product doesn’t get built by itself and impediments do not magically take care of themselves. But at the end of the day, without effective product ownership, Scrum Teams will rapidly crank out potentially shippable increments of stuff nobody wants — and building stuff that nobody wants is a surefire way to kill your business!

Value Hunting with the Product Owner

Value Hunting with the Product Owner

I coach my Product Owners to ruthlessly refine their Product Backlog to prevent onset of an Agile death march. A lack of proper attention to Product Backlog Refinement can lead to product decay, premature end of product life, and demotivation of the Development Team. 

In light of these risks, it's important to get Product Backlog Refinement right...

Read More

4 things - before starting a large Agile project

Question Backlog.jpg

In my classes, I often ask participants to create a question "backlog" of the things they would like to have addressed before the end of the class. The participants write questions, prioritize them, and decide when a question has been satisfactorily addressed. As the trainer, I determine whether a question is in or out of scope and facilitate discussion. Sometimes, toward the end of class, I'll ask the question's author to share with the class the answer they have learned.

In a recent class, a participant wrote, "What are the top 5 things that must be done in the 12 months before embarking on a large Agile project?" You may be thinking, "But Jim, you wrote '4 things...' in the title of this post. For those of you that have been reading these "4 things" posts, you know by now that I never stop at just 4. ;)

By the end of the second day of the class, without a specific, targeted discussion around this question, the question's author put together this poster from various related discussions that gave him insights for a possible answer.

Top 5 Activities.jpg

Top  5 activities to prepare for flagship Agile Product

  1. Educate the team/stakeholders of the benefits & expectations of the change
  2. Create a Meta team [a team to focus on the change initiative associated with the Agile adoption]
  3. Pilot 1 small product
  4. Create Product Backlog/Release Plan
  5. Choose the right Product Owner

 

 

Note that the list implies a faster start than 12 months with an experimental pilot to accelerate learning. Also, note the shift from an "project" to a "product".

Not a bad list. What would you include in your top 5?

4 things - Product Owner

4 things - Product Owner

A potentially fatal flaw for Scrum Teams is to step into execution before aligning on fundamental intent. A "ready, fire, aim" strategy can work if a Scrum Team is effective in the adapt phase of the inspect and adapt cycle, but for a new team that is not yet proficient in adjusting course, getting started in the wrong direction can be an impediment that the Scrum Team is not yet able to overcome.

Aligning on fundamental intent is the job of the Product Owner in Scrum. Getting this role right is key to success. The Product Owner is responsible for 4 key things:

Read More

The Virtue of Small

Small

Small

"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry One of the tricks that makes Agile work is keeping things small.  In practice, small may be the "secret sauce" in Agile.

Small releases, small iterations, small teams, small queues, small user stories (the "S" in the "INVEST" acronym) -- Small is good.  Small is beautiful.

Pareto

One of the tricks to keeping things small is Pareto. Also known as the 80/20 rule, the Pareto Principle basically states that 80% of the effect comes from 20% of the cause.

To see how the Pareto Principle applies in Agile, consider a feature. Most of the value of a feature is in the happy path, the default scenario. The happy path is the scenario where everything works as intended with no missteps. The edge cases or exception paths carry different values, but none are likely to trump the happy path -- not by a long shot. Quality specifications inform the value of  edge cases, and quality specifications may dictate that some edge cases are essential for a production release. Regardless, the happy path is where most of the value lies.  Very likely the 80% value or "effect" is in the happy path.

Product Owners can break a complex user story into multiple smaller stories by separating the happy path and the exception cases into separate user stories with each story representing a unique and distinct path through the feature. The order of these stories in the product backlog would be the happy path first, followed by the next highest value exception path scenario, and so on.

Since product backlogs almost always contain more than one feature, the stories associated with one feature would almost always be interleaved with stories from other features. The Pareto Principle tells us that the value in the subsequent stories after the happy path story starts to fall off at a very rapid rate. The diminishing returns of these exception path stories means that, at some point, the value of the happy path of a "lower" value feature might exceed the value of the next "not yet started" exception path story of a "higher" value feature.

In this way, the Product Owner plays a value optimization game, sequencing the items in the product backlog by comparing exception paths of one story to happy paths of others. As stories are completed or "done," the Product Owner determines readiness for production by considering the appropriate level of quality required for the features to be deployed.

The Macro is in the Micro

The applicability of the Pareto Principle doesn't stop at a user stories and the product backlog. It applies equally well at the product portfolio level.  The Pareto Principle shows us how small is beautiful. In truth, less is more.