The Importance of Value to the Product Owner
In Agile Development, the value of the outcomes plays a VERY important part in when and how work gets done. In fact, you might recall that the very first principle of agile software development reads like this:"Our highest priority is to satisfy our customers through the early and continuous delivery of valuable software."
Though Scrum supports this concept, the value of work is frequently not a factor in ordering the Product Backlog. What do we mean by value?
What is Value?
The easiest interpretation is “customer value” or “how badly does the customer want it?”
Could also include “how badly does the business want it?”
Probably shouldn’t include “how badly does the product need it?”
For example, an architectural change that MUST be done is probably not high value, it’s just something that needs to be done.
However, the BEST interpretation of value is “how much does the completion of the backlog item help us achieve our product goal?” That’s really the bottom line. A product goal, in Scrum, is the root of the Product Backlog.
For example, if your product goal is “By end of the third quarter, we will improve product performance by 25%” then your product backlog should be completely composed of backlog items that help you achieve that goal.
Once you do this, measuring value become absolutely simple.
Measuring Value
Measuring value is about the backlog item’s ability, when completed, to get us closer to our goals. The more the product backlog item impacts achievement, the higher the value. Once you embrace this concept, measuring value becomes easy:
You could use a simple categorization like HIGH & LOW or HIGH, MEDIUM, LOW.
You could use a quantifiable value like 1 to 5 or 1 to 10.
You could use value points (like story points, but about value instead of complexity).
Personally, I recommend using HIGH and LOW. You can add MEDIUM if you like. Keep in mind, though - the more categories of value (high, low, medium, 1, 2, 4, 5, etc.) the harder it will be to create consistency and the longer each value estimation will take. Believe me, using simply HIGH and LOW will get the job done.
The Benefits of Understanding Value
Once you have a clear understanding value, you’ll discover:
Making decisions about product backlog order
It’s almost always better to deal with HIGH value before LOW value. Granted, sometimes some LOW value goes first...
Architectural changes
Simple PBIs to give a new team momentum
It’s a technical prerequisite
Sometimes the MOST AMAZINGLY COOL feature is still a LOW value item because it simply doesn’t “move the needle” that much toward achieving the product goal.
Trimming the Tail
Also, consider this advantage of understanding backlog item value. In traditional project management (which is to say, “waterfall”), projects tend to “follow the plan” even going so far as to repeatedly change the plan to adapt to reality.
When tracking value, a product owner can carefully assess how much value will be developed by future Sprints in the same project. If the product owner is ordering higher value before lower value, at some point, the higher value items will begin to become scarce and only lower value items will remain. At this point, even if the “end” of the project hasn’t been reached, it makes sense to begin asking if the project should continue or end a little early.
Conclusion
IT is a business; building low value software when the cost of the production is the same is a poor business decision. It results in a much lower return on investment. By helping your product owner to make better business decisions, more value is produced and less time is lost producing low value (or no-value) waste.
