I was recently asked about the role of the Scrum Product Owner as it relates to earned value management (EVM). EVM is a traditional project management technique that provides a set of metrics to evaluate effort spent (work/schedule/cost) against plan. It is designed to measure project (performance) value.
However, the Product Owner’s role is to deliver business value through:
The Product Owner is more interested in monitoring the amount of business value accumulated over the project, or Earned Business Value (EBV), than project performance (EVM). EBV is the percentage of completed business value to planned business value.
EBV requires that a relative business value is assigned to each Product Backlog item either by the Product Owner independently or via a collaborative approach in which stakeholders use one of various methods to come to agreement on relative business value (business value points) per Product Backlog item. Two methods I particularly like to collaboratively derive business value points are:
Regardless of how it is determined, EBV may then be compared to the level of effort points (from the Scrum team’s planning poker) to order the Product Backlog items by return on investment (ROI). EBV may also be mapped on top of a release burn-up chart (or shown on a separate chart), measuring cumulative business value over time.
The Product Owner must also plan and manage product releases, so they should:
The end result is a consolidated set of visual graphics demonstrating progress against the release plan, which presents an easily understandable picture and provides the basis for internal executive and customer conversations.
That’s all well and good, but we need to be sure that our Scrum team(s), management, and customers understand these key points as they explore those visuals:
Adding earned business value tracking and simplified EVM to Scrum projects provides additional insight for release planning and may help clear some resistance for those Scrum teams who are introducing Scrum in more traditional environments.
When organizations consider the case for large application modernization initiatives, presenting both pros and cons of the exercise in money can help attract the attention of decision-makers.
The causes of failure in software projects are extraordinarily well documented.
As technology advances, mainframe organizations are increasingly pressed to transition to more modern platforms. Here are some of the most common misconceptions that hinder their mainframe modernization journey.
The cost of not modernizing mainframe systems is generally far greater than the time, effort, and money required to make the transition. Here's why.
As mainframes host mission-critical applications, it's essential to ensure that the modernization process is accurate and causes minimal disruption to business operations. This is where automated migration and testing tools come in.
Get in touch with our experts and find out how Astadia's range of tools and experience can support your team.contact us now