Professional Documents
Culture Documents
Domain 2 - Value Driven Delivery
Domain 2 - Value Driven Delivery
Management
Session 6
Domain II—Value-Driven Delivery
Forecasting the value of a project helps organizations decide whether the project is beneficial to
proceed or to stop the project (Fail Fast).
Product Owner is responsible for maximizing the project value; however inputs can be provided by the
entire project team.
On the contrary, if you were to receive the same amount of money in future ($10,000 in this
example), then its value today is less, due to:
• Inflation
• No interest earned
However, at times projects are also undertaken for regulatory compliance and performance
improvement purposes.
The financial feasibility study is performed by product owners to determine how profitable the project
would be and the analysis is reviewed by project sponsors. To forecast the financial feasibility of a
project the following metrics are widely used:
Usually this threshold is the point at which equity holders would receive a higher return than if they allowed the
investment to merely collect interest.
IRR is calculated using the formula:
Where,
ra= Lower discount rate chosen
rb= Higher discount rate chosen
Na = NPV at ra
Nb= NPV at rb
The IRRs of Projects A and B are 27% and 43%, respectively. Project B must be selected, as
it has a higher IRR than Project A.
Also, care needs to be taken to ensure that the definition of priorities does not change or get
diluted over the course of the project.
There are three prioritization techniques that can be applied within Agile:
1.MoSCoW
2.Kano Model
3.Relative Weighting
The term ‘Pruning the Backlog’ refers to the process of
continuously prioritizing the backlog.
Under this technique, the requirements are prioritized based on the following:
• Must—These requirements are mandatory
• Should—These requirements are highly desirable, though not mandatory
• Could—These requirements are nice to have
• Won’t—One should not work on these requirements at this point in time
If Tom has to use the MoSCoW prioritization technique, which of these requirements will fall under
the categories of Must Have, Should Have, and Could Have?
Further, risks reflect the challenges of implementing the feature, and costs reflect the actual costs
of implementing the feature.
Each feature is prioritized based on its relative weighting for Benefits, Penalties, Costs, and
Risks. Each feature uses a relative scale of 1–9 to determine its rating.
Some of the non-functional requirements are global in nature and can be applied across the all
requirements, while some are specific to individual requirements.
MGP 535- Agile Project Management 34
Prioritization of Non-Functional Requirements
Non-functional requirements should also be
prioritized in-line with other functional
requirements.
Points to remember:
• Proactively addressing the non-functional
requirement helps in minimizing the probability of
project failure.
• Non-functional requirements also undergo
progressive elaboration and emerge throughout the
project lifecycle.
• Some of the non-functional requirements are
evident at the beginning of the project, however
they need to be actively sought out as the project
progresses.
Addressing these requirements helps in improving the quality and value of deliverables.
If these requirements are missed or discovered later, it becomes difficult to address them.
The Product Owner needs to ensure that the specialists in these fields are involved while
envisioning the product and capturing requirements.