I am a developer on a scrum team, and a user story has been created:

The application takes a few hundred numbers in and performs a complex calculation on them, and gives one decimal number as output. This is the whole point of the application. 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.)

They know it is wrong because the previous vendor who built the application created a spreadsheet that would also calculate the number; over time, the spreadsheet and/or the application have been changed and now the outputs no longer match.

Is this a valid user story?

We are contractors and the contract has to be renewed every three months, so my management is reluctant to force them to uphold their responsibilities (assuming it is their responsibility to know how the thing works and how it got into a state of disrepair.)

  • While it's helpful to have a PO who understands the implementation, especially when discussing the trade-offs and level of effort for stories with the rest of the team, it's not strictly necessary. However, a goal that no one understands or can measure is an anti-pattern. I provide a more comprehensive response to this X/Y problem below.
    – Todd A. Jacobs
    May 24, 2017 at 3:55

3 Answers 3



If this is a contractual dispute rather than a process problem:

  1. You're violating core agile values and roles defined by the Scrum framework.
  2. 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:

  1. 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.

  2. 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:

  1. 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.

  2. 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.

  3. 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.  
         | 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.


User stories are about deliveries. There are other types of activities that are needed to be done in a development team.

Please take a look at the quadrant below:

  • If Dev Team and Business know how and what to build, they Build it
  • If Dev Team knows how to build, but Business doesn't know what to build, they Experiment it, meaning they build something to learn
  • If Dec Team doesn't know how to build but Business knows what to build, they Spike it, they research to learn how to build
  • If both doesn't know what and how to do, they need to learn, talk to customer to educate themselves what to build and research to educate themselves on how to build it at the same time

Not everything is a user story and can be described as one!

Build v.s. Spike v.s. Experiment v.s. Learn


Is it a valid user story? Certainly.

I would write it something like this:

As an application user I want to be sure the output is accurate so that I don't make decisions using invalid results

  • Isn't this user story too vague? (According to the the INVEST principle) May 24, 2017 at 6:53
  • 1
    Quite possibly. But the INVEST principle is for stories going in to sprints. It is not unusual to have less refined stories on the backlog that need to be worked on before they get to the top of the backlog. May 24, 2017 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.