Agile Insider
Published in

Agile Insider

The just-in-time Product Owner

Photo by Drew Coffman on Unsplash

The just-in-time Product Owner doesn’t have to worry. Their work is never outdated. They are never endlessly piling requirements into the backlog while their product and their customer’s needs change around them. They deliver just enough, just in time. They are the masters of Now.

The Problem

Product requirements age. This is at the foundation of the Agile methodology. Customers change their minds, or the industry advances in some new way, and requirements which were tediously gathered 3 months ago become irrelevant. If you have ever rearranged your office, worked in it for a few weeks and realized that you wanted it arranged some other way, you have lived a perfect example of this. Customers are human; they change their minds and what they want or need today does not have much bearing on what they will want or need tomorrow.

The three common responses to this problem

  • Do nothing: Product Owners will gather detailed requirements for each feature request, as they come in. Then, when the feature is finally prioritized, they will go back to the customer and find that they’ve changed their mind, forcing the Product Owner to re-write requirements and redo mock-ups, causing double work.
  • Freeze requirements: The Product Owner will tell the customer that they aren’t allowed to change their mind. They still gather requirements early on, but when the feature is finally prioritized and it is discovered that the customer has changed their mind, the Product Owner says “sorry, these requirements are locked”. This method almost guarantees frustration all around, along with less value being delivered to the customer.
  • Just-in-time requirements gathering: Being a just-in-time Product Owner combats this propensity for change with fierce adaptability. Product requirements are delivered to developers just in time for development, and with just enough detail to develop. Feature requests are kept at the bare minimum of detail until they are coming up on the development schedule one to two iterations in the future. Until that point, the detail which is maintained is just enough to estimate and prioritize. Once they are prioritized and scheduled one to two iterations in the future, the Product Owner creates mock-ups and gathers the requirements needed for development.

Scott W. Ambler’s diagram shows this ramp-up of detail well, illustrating that low priority, unscheduled items are loosely modeled, but as they become more highly prioritized, they become modeled in greater detail.

By Scott W. Ambler

The risk of just-in-time

The one risk of practicing just-in-time is that a Product Owner will miss their deadline for having mock-ups completed, requirements gathered, and everything customer-approved. This is a real concern, but is less common than you might think. It is often mitigated tremendously by having developers who participate actively in the discovery process and are willing to accept a small level of uncertainty while late requirement are polished up.

So why not try it? Be a just-in-time Product Owner. Never worry again that your work will be outdated or that your customers will change their minds. You don’t need to worry. When a feature request comes in, you gather only what is needed to estimate and prioritize it. When features are one iteration out, that’s when you strike. You gather just enough, just in time. You are the master of Now.

Sources

Agile Requirements Modeling

by Scott W. Ambler

New to agile? Remember one thing: Just enough, just in time

by Bob Hartman

JUST-IN-TIME DELIVERY: THE STORY OF AGILE

by Aby Yohannan

How Do You Conquer Just-In-Time Requirements?

by Alan O’Callaghan

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store