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.
Everybody agrees that automation is key to mainframe modernization regardless of the selected transformation approach, particularly in replatforming or refactoring projects. Not everybody, however, has the vision to automate the journey all the way.
COBOL talent shortage is a major mainframe modernization driver and that’s when every IT leader must make a decision about what will happen to the COBOL programmers in this scenario.
Get in touch with our experts and find out how Astadia's range of tools and experience can support your team.contact us now