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?

• 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.

Scrum defines a Product Backlog Item as having four required attributes:

1. A description (for example, “add a class to a student’s schedule”)
2. A rank (the PBI might be 1st, 10th, 150th in the Product Backlog)
3. A size estimate (Scrum doesn’t care how you do it, but estimating size is required), and
4. A value estimate (again, Scrum doesn’t care how you do it, as long as you do estimate value).

Estimating value doesn’t have to be difficult:

• You could use $$ (really hard to do this well)
• 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)

The benefits of understanding value

1. Making decisions about product backlog order
2. 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 add much incremental functionality to the product.

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 team producing it doesn’t change with the value produced is a poor business decision. By enabling your product owner to make better business decisions, more value and less waste is produced.