Know and optimize your output of business value in several easy steps to get the most ROI out of the Scrum framework.
Scrum is like a modern, sophisticated meat grinder. Compared to the traditional knife method or heavy manually handled cast iron meat grinder, it is designed to process your “raw meat” into tasty meat loafs your clients will love. With transparency, inspection, and adaptation, not only will you get the loaves in the most efficient way, but you will also have a fast feedback loop that is required to improve your production while moving further on with your product.
Like with the meat grinder, the quality that goes out does not entirely depend on the grinder itself. You will definitely aim for the highest quality of raw meat. And, while the Scrum process itself is pretty straightforward to put in place, the quality and value of the product delivered rely heavily on the people involved in the process: the development team, the Scrum Master and, of course, the Product Owner.
This article won’t try to explain how these roles collaborate within the Scrum framework; you can refer to the Scrum Guide for basics on this topic. My goal here is to address the one key concept that lies at the heart of any business model: the business value. Your ability to understand it, measure it, and use it to order and optimize your product backlog, that’s what will make a difference in the delivery of your product: tasty loaves everyone craves for over uneatable chunks nobody ever comes close to.
Business value or how to find your “true North”?
We live in a world full of choices: our respective individual and professional lives are overflown with a variety of “stuff” we can do at any given time. Of course, not all choices are worth selecting as illustrated in the following Venn diagram:
If you have two out of three, it’s just not working! Let’s say you have time and money to do something, but no ability whatsoever: there is a very real possibility you will not achieve a satisfying outcome. The sweet spot lies on the intersection of the three circles; these should be considered for making meaningful choices.
The same goes for businesses and organizations. On a larger scale, it is important to define which course of action is worth pursuing. At any given time, this should be the Product Owners’ “true North” to refer to when playing out their role in the Scrum team. Here is a similar Venn diagram that can help find a company’s “true North”:
As Jeff Sutherland puts it when describing these relationships in his book titled Scrum—the Art of Doing Twice the Work in Half the Time:
“If you concentrate only on what you can build, you can end up making something that nobody actually wants, even if you are passionate about it. If you concentrate only on what you can sell, you can promise things you can’t build. If you only build what you can sell but aren’t passionate about it, you’ll end up working hard to build mediocrity. But in the center, that sweet spot is a vision rooted in reality—a vision with a real possibility of becoming something great.”
There lies your “true North”: the course of action worth pursuing. Once you figure it out, the real edge between one company and another pursuing a similar direction lies mostly in the ability to deliver it faster and better than everyone else. And that’s precisely what Scrum has been designed to achieve.
The Product Owner or how to deliver value in the optimal order?
Thousands of articles and books have been written on that topic alone, which shows how important this role is within any Scrum team. While many of these provide us with meaningful nuances, when it comes to the core of what you have to expect from your Product Owner, four essential characteristics emerge (according to Sutherland):
- Knowledgeable about what can and can’t be done to translate hours of work into meaningful increments of value aligned with the “true North”. Lyssa Adkins refers to this as “business value microdefinitions”: balancing every aspect of a business value definition (ROI, profit, risk reduction, knowledge gained) to set the next short-term critical milestone in the pursuit of the company’s “true North”.
- Empowered to make sound and final decisions about what needs to be done to translate a vision into the highest-value product in an iterative and incremental way.
- Available to help the team in understanding what needs to be done and why it needs to be done.
- Accountable for the value that is finally delivered.
I haven’t detailed the different aspects, because ultimately it usually results in some expression of a money flow (ROI, profit, cost reduction, investment with expected monetary gain over time, etc.).
The final clients: who are they and what do they truly desire?
Once you figure out what you can do, sell, and be passionate about, it’s time to figure out who will buy it. And you do not only want a satisfied client, a one-time buyer of your product. What you truly crave for is what Ken Blanchard calls a “raving fan”. He defines this particular type of client as “one who is so devoted to your products and services that he wouldn’t dream of taking his business elsewhere and would sing from the rooftops about just how good you are”.
Finding these raving fans may be a stroke of luck, but most likely you will rather use a more empiric approach. Personally, I love the way this has been implemented at Menlo Innovations, as described in Richard Sheridan’s book titled Joy, Inc.: How We Built a Workplace People Love. As Sheridan continued to build Menlo Innovations, he and his team figured out that there were serious limitations in the way traditional methods (and even Agile approaches, though to a lesser extent) created software products delighting the final client.
Social sciences, and more specifically anthropology, helped his company to fill the gap. Anthropology (i.e., the science of people) implies observing humans in their natural environment to identify behaviours, artifacts, interactions, and social systems. A new role has emerged, a “high-tech anthropologist”, who is present in all Menlo’s projects. This person provides the team with unique first-hand knowledge by observing final users’ in their natural environment.
For instance, if you have to design a wedding planning software product, the anthropologist will spend time observing all activities to be carried out throughout the various stages required to plan a wedding (bridal shows, churches, synagogues, wedding dress and cake shops, jewelry stores, banquet halls, etc.), observing and discussing with people taking part in the wedding preparation process.
This way of doing is also aligned with the Gemba Gembutsu Genjitsu principle issued from the Toyota Production System created by Taiichi Ohno, which implies that, to understand well how work is being done, you have to “go and see” by yourself where the work is actually being done.
Once this initial phase is over, personas will be created based on the observations. Each persona must be as specific as possible. Let’s say you wish to represent a mother-in-law. It could be a certain Kathleen Turner, 52 years old, who will help with her daughter-in-law’s wedding. She is not using her computer a lot. Her goals are to help plan the wedding of the century, use a computer to do so if it saves her time, and avoid situations where she doesn’t understand the terms, as it makes her feel stupid.
After having created several personas, the Product Owner selects the final client (one precise persona that the product will likely delight the most) and two to three secondary targets (that we will try to delight as long as it doesn’t impede the delight of the final client). Why only one client? Because if you try to please everyone, you will likely finish pleasing no one.
The magic behind using anthropology is that you uncover the needs a final user would never have brought up by himself in an artificial setting (e.g., project war room, meeting room, focus group, etc.). Basically, you observe him to see what he is unaware of himself. Then, you work with the Product Owner to order the backlog accordingly.
Knowing your final client also provides you with a key insight into his capacity to accept change and the optimal rate at which he or she is willing to integrate it. Shortening the feedback loop to a one-day cycle is of no use if you have no one around to provide you with relevant feedback.
So what do we do first?
You are almost set up! You have figured out where your business value lies, who is your PO, and who is the targeted client. There is one simple question left to answer: where do I begin?
Thankfully, economics is not lacking relevant notions to help you get started. Of course, the aim of this post is not to teach you the basic notions of microeconomics, but to provide you with a tool to quickly get you started. One model particularly stands out, especially because of its roots in solid scientific theory: Weighted Shortest Job First (WSJF).
Shortest what, weighted how?
Founding father of the Lean product development cycle, Don Reinertsen states that if you were to focus on a single variable while ordering your product backlog, the cost of delays would be your best candidate. It may be summarized as how much does it cost us as a company to delay the delivery to our final client of this particular item of the functioning product. It’s weighted because you want to ponder it by the length of the delay in order to have a meaningful base of comparison between items. WSJF is used in Scaled Agile Framework® (SAFe®) to prioritize jobs when determining the content of the next Agile Release Train (ART).
The formula is as follows:
Scaled Agile®
User-Business Value represents precisely what you have figured out until now.
Time Criticality is a bit tricky and it can be summarized as the natural item’s value decay over time in the eyes of the client. For example, a functionality designed to help sell Christmas items loses a great deal of its value around December 24th.
Risk Reduction|Opportunity Enablement Value is the “hidden” benefit of the functionality (or, at least, the less obvious). Will it help us greatly reduce risk (and potential costs of it occurring) for the whole product? Will it enable us to identify business opportunities of greater value than what we are currently doing? Will we learn enough to reduce significantly further product development costs? Etc.
As we speak about all the potential and future values and reductions, we’d better use the relative values when figuring out each of them. Due to what we commonly call the “cone of uncertainty” (or the “funnel curve” as it was first introduced to the field of software development by Barry Boehm in 1981), there is a scientific conviction that our estimation of effort and duration in absolute values is highly inaccurate prior to the effort and only clarified over time, with experience.
This theory is behind many Agile practices, especially when it comes to planning the next iteration and estimating the work that has to be done. Therefore, SAFe® suggests using a relative comparison technique like the Fibonacci sequence or any other similar practice.
Like anything else with Scrum, as imperfect as your initial estimates will be, they will get better and more informed over time. So keep learning and get the most out of your backlog.
And then…
Of course, as you progress, you will get the feedback that will help you improve your knowledge of the business value. And you will want to optimize and get more and more out of it. But that is what I intend to cover next time. Until then, try to find your “true North”!
No Comment