Below is a collection of the key knowledge addressed in Domain II Value-Driven
Delivery and the 14 tasks related to the domain:
Value-driven delivery is an overarching principle for Agile projects. Projects are carried out to realize values (e.g. economic benefits, competitive advantages, reducing risks, regulatory compliance, etc.)
In terms of Agile project management (and the PMI-ACP exam), prioritization is the process where customers organize / select product backlog/user stories for implementation based on the perceived values
Value-based Prioritization is to organize things so that the most important ones that deliver values are to be dealt with first
Return on investment (ROI) / Net present value (NPV) / Internal rate of return (IRR)
are metrics to assess prioritization based on monetary values return on investment (ROI) – the values a project realized (using
present value) compared to the investment; a positive ROI means the project is profitable
net present value (NPV) – the net future cash flow (profit – expenditure) in terms of today’s value (adjusted for future inflation, etc.); a positive NPV means the project is profitable
internal rate of return (IRR) – this is somewhat like the interest rate of the investment; the higher the positive IRR, the more profitable the project
Customer-valued Prioritization
deliver the highest value to the customers as early as possible
the backlog should be customer-valued prioritized while taking into account technical feasibilities, risks, dependencies, etc. in order to win customer support
Value Prioritization Schemes
simple schemes – rank from high to low (priority 1, 2, 3, …)
Moscow prioritization scheme – Must have, Should have, Could have,
Would like to have, in future
Monopoly money – ask customers to give out (fake) money to individual business features in order to compare the relative priority
100-Point method – customers are allowed to give, in total 100 points, to various features
Dot voting / Multi-voting – everyone is given a limited number of dots (~20% of the number of all options) to vote on the options
Kano analysis – plot the features on a graph with axes as Need Fulfilled /
Not fulfilled vs Satisfied / Dissatisfied, each feature will then be classified as “exciters, satisfiers, dissatisfiers, indifferent”. Exciters are of the highest values.
Requirements Prioritization model – rate each feature by benefits for having, the penalty for not having, cost of producing, risks, etc. and calculate a score using a pre-defined weighted formula
CARVER (Criticality, Accessibility, Return, Vulnerability, Effect, and Recognizability) relative to the objective and mission of the project
Criticality – how important it to be done upfront
Accessibility – can work on it immediately? or depends on other work/skills?
Return – ROI / NPV / IRR
Vulnerability – how easy to achieve the desired results?
Effect – what are the effects on the project (help moving towards the goal of the project)?
Recognizability – have the goals been clearly identified?
Relative Prioritization / Ranking
an ordered list of all user stories/features to be completed with 1 being the highest priority
when new features are to be added, it has to be compared, in terms of priority, to all current features
the schemes list above can be used to assist the relative prioritization/ranking tasks
Minimally Marketable Features (MMF)
the minimal functionality set (a group of user stories or a package of features) that can deliver values (e.g. useful) to the customers / end-users
a distinct and deliverable feature of the system that provides significant values to the customer (can be sold/used immediately) chosen for implementation after value-based prioritization
can reap the return on investment instantly
Minimal Viable Product (MVP)
The minimal product (with just essential features and no more) that allows can be shipped to early adopters to see and learn from the feedback instantly. The concept is somewhat similar to Minimally Marketable Feature (MMF) in which MVP is the first shippable product with the first set of MMF.
Compliance
conforming to a rule, such as a specification, policy, standard, or law (e.g. regulatory compliance)
compliance usually requires documentation, which is somewhat against the principles of agile (working software over documentation)
a balance has to be struck (maybe with the help of Agile compliance management systems)
Requirements Review
a group of users and/or recognized experts carrying out reviews on the documented requirements
to ensure that:
requirements accurately reflect the needs and priorities of stakeholders
requirements are technically feasible to be fulfilled
Earned Value Management (EVM) for Agile Projects
Earned Value Management is a tool used in traditional project management to measure the progress (in terms of realization of values) of the project
In Agile, EVM is the measure of cost performance of the Agile project though the estimate and actual costs (money spent) can be plotted as an S-curve graph to clearly show whether the project is under-or over-budget, it does not tell whether the progress of the project is ahead of or behind schedule
Value (story points and money) is calculated at the end of each iteration for work done
For the construction of the graph for EVM: The baseline for comparison:
number of planned iterations in a release planned story points in the release planned budget for the release
Actual measurements:
total story points completed number of iterations completed Actual Cost (actual spending) to date
any story points added/removed from the plan (as Agile project requirements are ever-changing)
Plotting the chart:
x-axis: iterations / date
y-axis: i) story points planned; ii) story points completed, iii) planned budget; iv) actual costs
discrepancies between i) and ii) / iii) and iv) reflect the performance of the release
Formulas for EVM
Schedule Performance Index (SPI) = Earned Value / Planned Value Cost Performance Index (CPI) = Earned Value / Actual Cost
EVM does not indicate the quality of the project outcome, i.e. whether the project is successful or not
Approved Iterations
After the time assigned to an iteration has been used up, the team will hold a review meeting with the stakeholders (mainly management and customers) to demonstrate the working increments from the iteration. If stakeholders approve the product increment against the backlog selected for the iteration, the iteration is said to be approved.
Approved iterations may be used in the contract of work as a way to structure the release of partial payment to the contractor.
The following domains will be published later on with separated articles, STAY TUNED!