TL;DR
If this is a contractual dispute rather than a process problem:
- You're violating core agile values and roles defined by the Scrum framework.
- Consult your company's contracts manager or legal counsel.
Otherwise, realize that the Product Owner has a problem, although it's likely not the problem he currently thinks he has. Collaborate with him to find solutions that will fit within the project's scope and resources, and negotiate with him to postpone or replace stories on the Product Backlog that are less vital to creating a viable product.
The Product Owner Has an X/Y Problem
The business line/product owner does not know how this number is calculated, and has created a user story for the dev team to reverse-engineer the code and determine how the calculation is performed (And subsequently, why it is wrong.)
The Product Owner actually has two problems:
He doesn't know what the correct number should be.
Just because the spreadsheet provides a number doesn't mean that number is correct. It would be more accurate to say that the Product Owner assumes that the spreadsheet's calculated value is the source of truth, and that you should be using its value as a test fixture in your development.
The proposed user story misses the point. Neither you nor the Product Owner really care about how the value is calculated; what you want is for the results of both the spreadsheet and your product to always arrive at the same value.
In other words, it's an X/Y problem. The PO has problem X, and has decided a priori that solution Y will solve it. When you factor in the self-inflicted X/Y problem, the PO now has three problems to contend with, rather than just the original two!
Possible Approaches
The Product Owner can do a few different things, alone or in combination. These include:
Writing a user story that delivers a feature, rather than an implementation.
A better user story would read something like:
As a user,
I want product calculations to yield the same results as the spreadsheet
so that the results are consistently identical.
There may still be some reverse engineering involved, but the reverse-engineering is no longer the point. The goal is to have identical values, regardless of how those calculations are actually implemented.
Explicitly allocate budget, time, and resources towards reverse-engineering the spreadsheet.
In Scrum, the Product Owner defines the priorities, but must live within the team's capacity and the budget constraints of the project. In other words, the PO can allocate the finite resources of a project towards any objective he likes, but this isn't "free." It takes capacity away from delivering other features.
Take a greenfield approach.
Another valid option is to assume that neither the spreadsheet nor the current product calculations are correct, and to work with stakeholders to identify correct inputs and outputs. You might develop a set of acceptance criteria using Cucumber, for example.
Scenario Outline: Foo Calculations
Given a set of inputs for the Foo Calculator
When I calculate Foo with <value> as an input
Then I should get <output> as a valid result.
Examples:
| value | output |
| 12 | 6 |
| 16 | 8 |
| 20 | 10 |
This technique takes the approach of saying that how the values are calculated is irrelevant so long as the correct answers are computed. Because it's a behavior-driven approach, it allows the Product Owner to collaborate on the solution by helping to define both valid inputs and matching results. This is the essence of BDD and ATDD, and allows additional stories to be developed from a set of testable criteria.
All three approaches are valid. However, if the "source of truth" is a set of spaghetti code, then I would certainly recommend the BDD/ATDD approach as the one that is most likely to get the PO what he really needs, rather than what he thinks he wants.
Fix the Process: Re-Engage Through Active Collaboration
A core agile value is to prefer collaboration over contract negotiation. The team's job is to work with the Product Owner to find a solution to his needs. So, your goal isn't to say "yes" or "no" to his requests; it's to make costs to the project visibile so the PO can make informed decisions and trade-offs.
If the Product Owner has a problem that will take 18 months to solve, and is willing to pay for it, then you have no problem. If the Product Owner has an 18-month problem and only three months of budget with no possibility of extension, then the Product Owner must prioritize the work that should be attempted within the resources of the project.
As a Scrum Master or a member of the Development Team, it's not your place to tell the Product Owner what the priorities should be. However, a good Product Owner relies on the rest of the team to help determine level of effort, and to work with him to identify different approaches to implementation that meet the project's goals.
So your team needs to huddle around this with the Product Owner, and discuss scope, costs, and level of effort of the available solutions. You can negotiate! However, it is ultimately up to the Product Owner to set the priorities.
If a Product Owner chooses not to work with the team and finds himself at the end of his project resources with nothing to show for it, then that's his responsibility. Never set the PO up for failure, but realize that in the end managing the project's success through the allocation of Sprint capacity is fundamental to the role of Product Owner. In short, if he breaks the process or the "contract" of collaboration, then he gets to keep both halves.
