Book Excerpt from "I Want To Be An ACP" - Fundamentals of Value-Driven Delivery

This article is an excerpt from the Book - I Want To Be An ACP. 

It is from Chapter – 3: Value-Driven Delivery. 

For the partial index of the book, refer: Book Index - I Want To Be An ACP.

********* 

Fundamentals of Value-Driven Delivery

“Value-driven delivery” is perhaps the most important domain in PMI-ACP certification. This is what Agile development is primarily focused on – delivering value to the customer, either external or internal. No wonder, maximum number of questions comes from this domain. In fact, the first principle in the Agile Manifesto says this:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

The focus in Agile is delivery of valuable software or simply delivering business value. As a matter of fact, in agile, we are not only focused on value, but on delivery of highest value first (and early) to the customer. 

But, how do you define what gives value? How do you find out which one of the items in the backlog will give the highest value? Or in other words, how do you prioritize among the items giving the most value? In this chapter – Value-Driven Delivery, we will see the answers to these questions.  

This domain’s key tenet is this:

“Provide value based delivery in an incremental way based on priorities. Take feedback and incorporate them for future increments.” 

As per PMI’s Exam Content Outline, “Value-Driven Delivery” domain has 4 sub-domains with related tasks.

. . . 

. . . 

3.2 Business Value 

When we talk of value in any organization, we are primarily talking of business value. But why value is important in Agile? Let’s see. Organizations can be broadly divided into 3 types [9]:

• Profit organization: Organization that yields a return for its owners.
• Nonprofit organization: Organization that uses surplus to help pursue its goal.
• Government organization: Organization under government ownership.

While every organization may not be business or profit driven, every organization conducts business related activities. They conduct these activities to attain business value. In other words, if there is no value from the activities planned to be taken, organizations – for profit or not for profit or government owned - won’t be doing them. 

As defined by PMI [9], “Business value is the entire value of the business. It is the total sum of all tangible and intangible elements.” Business value can be short, medium or long term depending on the organization. And business values are mostly expressed in financial terms for an organization. 

3.3 Features to Benefits to Value 

But, where does value come from? Value comes from benefits, which are delivered by projects inside a program or a portfolio. Value comes up when the benefits are realized in the hands of the customer(s).

PMI [9] defines benefit as: “A benefit is an outcome of actions, behaviors, products or services that provides utility, value or a positive change to the intended recipients, which can be the sponsoring organization as well as the intended stakeholders.” 

Simply put, benefit provides value to the intended stakeholders. Benefits are typically measurable improvements in financial terms, but they can also be intangible or in non-financial terms. Examples of benefits are:

• A 25% increase in revenue or gross margin (financial)
• A 30% increase in sales (financial)
• Improved employee morale (non-financial)
• Faster response time (non-financial)

The projects undertaken by the organization give outputs, not benefits. The outputs from projects undertaken by the organization, are converted to outcomes, which are then translated to benefits. 

Let us take an example. Your project is building a smart phone; hence the output is the “smart phone”, i.e., what product will be delivered by the project? Outcomes tells about the features, i.e., what users can do better with the product created? In this case, with the help of the smart phone, the outcomes are - communication is better and quicker, can access social media round the clock and so on. Then what are the benefits? Benefits are mostly noted in measurable improvements – so in this case by phone we have “response time is reduced to zero” or “communication cost reduce by 50% over landlines” and so on.

So, to sum-up, here is what we get.

• Outputs: Products that the user will use.
• Outcomes: Things that the users do differently or better.
• Benefits: The measurable (most of the time) improvements.Benefits can be tangible or intangible, qualifiable or quantifiable, financial or non-financial.
• Value: Value is created when benefits are realized in the hands of customer(s). 

But here we are talking of value in Agile mode. How does it happen here? Well, agile development is mainly focused on deliverable valuable software, which happens primarily via working software. In fact, one of the 4 core values per Agile Manifesto is: “Working software or product over comprehensive documentation”. 

And this value is directly complemented by many principles out of 12 principles such as:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Working software is the primary measure of progress.

As noted before only working software gives value to the customer. In Agile mode, this  happens early, frequently and in an incremental way. That differentiates it from predictive mode of development. 

Alright! So, we need value and value comes from benefit. But how do outputs get converted to outcomes? Outcomes are noted in features of a product. In every product, we talk in terms of features – which are actually requirements, functional or non-functional. Features are part of the Product Backlog (PB) and they are called as Product Backlog Items (PBIs). PB is a live log of requirements as we saw in previous chapter for many Agile methodologies such as Scrum, XP. In Agile, we do not have exhaustive requirement documents or design documents – rather one document called Product Backlog. 

These features or requirements are written in the form of user stories. 

Let's talk of about User Story briefly here. Because, it is User Story, which actually talks of business value.

Introduction to Use Story

A User Story describes the functionality that will be valuable to either a user or purchaser of a system or software. User Stories are written on cards. The cards are typically 4-inch by 6-inch, in size. In real time, they will be in the form of sticky notes or physical paper cards.

The user stories are written in this format: 

“As a <role>, I want <need>, so that <business value>”.

. . . 

. . . 

*********

This section is further explained in the book with: 

• More on User Story, which actually talks of benefit/value.
• How does feature translate to benefit and finally to value?
• How will you calculate the financial value of these features?

It is further followed by Accounting Principles, Prioritization, Relative Priorization, Non-Functional Requirements (NFRs) and Priorization of NFRs, Incremental Delivery, Backlog Refinement (grooming), Considering Risks in Value-driven Delivery, Visualization of Value Delivery, Delivering Value with Quality, Agile Contracting, Agile Compliance, Agile PMO. These can be seen from the index of the book.

Other Excerpts from Book:

• Book Exceprt from "I Want To Be An ACP" - Four Values of The Agile Manifesto

Book Available for ACP Exam Prep:

• New Book for ACP Exam Prep: "I Want To Be An ACP"