The Product Owner at MegaEnergy

The Situation at MegaEnergy

MegaEnergy owns gas pipelines throughout North America and leases them to gas and oil producers. Everything about the company is large, from the length of its pipelines to the size of its projects. MegaEnergy’s pipelines run through private property, and MegaEnergy has formal agreements with the property owners agreeing to pay them annual royalties. At the start of every calendar year, MegaEnergy sends out royalty checks. This might seem like a simple operation at first. But when you consider how frequently land ownership changes, you can see how complex an undertaking it really is.

To know where to send royalty checks, MegaEnergy had to know who owned each parcel of land. Its method of determining land ownership was archaic. About three months before the end of each year, MegaEnergy would print out a list of all the land that its pipelines traversed. These lists would be sent to various state and provincial government land registry departments. For a per-item fee, these departments would research and return to MegaEnergy the name and address of the current owner of each piece of land. MegaEnergy staff would check these names and addresses against the ones that it had recorded in its system and make any necessary changes. The entire process was extravagantly expensive and unnecessarily time-consuming. All communication with the various levels of government was on paper, and as a result, the MegaEnergy land department always looked like a paper factory.

The company had already undertaken two efforts to automate the process, and both had failed. These efforts were called the Title project. Because every state and province had different procedures, processes, and ways of communicating land ownership information, the MegaEnergy land department had trouble finding a common way to obtain and process information from the different government agencies. Compounding the problem, Mega- Energy managers had decided to couple the automation project with a project to remove the MegaEnergy land system data from the mainframes and reimplement it on less expensive servers.

The project had just been reconstituted for a third try when MegaEnergy decided to try using Scrum. Nothing else had worked, so what did MegaEnergy have to lose? Besides, it seemed as though Scrum would be the perfect development process for this project, given the great complexity of the situation. Ruth, a project manager from one of the previous attempts, was appointed ScrumMaster. Jane, the head of the MegaEnergy land department, was designated Product Owner.

The Product Owner in Action

Ruth and I helped Jane construct the Product Backlog. Because so much work had already been done during previous attempts, our task was relatively easy, although it soon became clear how important it was. Prioritizing the automation process over the move away from mainframes enabled us to get a grip on the project and give the team some work that it could actually accomplish.

Each Sprint produces business functionality that is potentially implementable. But because there is so much work to be done on product architecture and infrastructure during the first few Sprints, these Sprints deliver far less functionality than later Sprints. Accordingly, we minimized the amount of business functionality for the first Sprint. In the MegaEnergy project, Ruth and Jane decided that the team should try to automate only the title feed from the government agency that it knew best: the provincial government of Alberta.

Jane presented the Product Backlog at the Sprint planning meeting. As she and the team looked it over, they saw an opportunity. The MegaEnergy land database contained all titles on which royalties were owned. A data feed could be obtained from Alberta that contained only ownership changes over the last 12 months. Transactions could then be constructed for every hit between the feed and the land database. A land analyst in the MegaEnergy land department would reconcile these and update the MegaEnergy land database only when appropriate. The analyst would no longer need to check the name and address of every single title. By automating the feed, providing reconciliation screens, and reversing the process, the volume of work could be significantly reduced and automated at the same time. The team was pleased with this discovery. Now it could reformulate the land database to support the new requirements, learn and test new server technologies, and construct a generalized XML data stream that the land department might be able to use in interactions with every government agency.

Thirty days later, at the first Sprint review meeting, the team presented the product increment that it had produced during the Sprint. Jane had worked with the team throughout this period and already knew what would be presented, but she was delighted nonetheless. She asked me to explain what I’d meant when I said that the functionality demonstrated at the Sprint review meeting must be potentially ready for implementation. I told her that at the subsequent Sprint planning meeting, she could ask for this increment to be implemented during the next Sprint. Jane chose to do so and conducted a two-week implementation Sprint. Because most MegaEnergy pipelines originated in and were fed through Alberta, the functionality produced during this Sprint immediately reduced the land department’s workload by more than 40 percent.

The Product Owner’s Value

The Product Owner is responsible for the ROI of the project, which usually means that the Product Owner chooses to develop product functionality that solves critical business problems. Jane was able to fulfill this responsibility by sorting priorities in the Product Backlog to reflect requirements with the highest business value. She was also able to call for releases of functionality when the business benefit more than offset the costs of implementation. While Jane was watching the demonstration during the Sprint review, she realized how much this single increment of functionality could do for her department. She had checked with the team and confirmed that implementing this one increment immediately wouldn’t cause any complications down the line.

Traditionally, customers get to state the requirements that optimize their ROI at the start of the project, but they don’t get to assess the accuracy of their predictions until the project is completed. Scrum lets the Product Owner adjust the ROI much more frequently. Jane was able to realize business value within 45 days, even though she had failed to realize any value during the previous two failed attempts at automation. MegaEnergy realized ROI almost immediately on this project. Also, through Jane’s wise selection of an implementation, MegaEnergy was able to see how rapidly automation can bring business benefits.