> Some good points Adam. We view frameworks a bit differently(but not too much), but that's not the point of this discussion, and I certainly don't want to get sidetracked on that. lol.
> > Why should the customer pay for a poor technical decision you made somewhere up the line?
> In the scenario I described, I made it clear that one can assume it was a good technical decision.
I think one must assume that it is a poor technical decision given
that you had to completely reverse it in the midst of development.
If you had used a crystal ball to see where you were going you would
have only chosen the latter framework. Most framework builders assume
that you have such a crystal ball, in part because they thought they
were using one to write the framework.
> I'm not asking anyone to accept a poor technical decision, and I'm also not thinking that the PO is the best authority on whether a technical decision is poor or not. I do think, though, they are the best authority in Scrum on whether a Product Backlog item provides the intended value or not.
He must be the authority on what has value per se. That is what
"Product Owner" means in Scrum. In practice, however, he needs to have
a lot of conversations to validate these decisions.
He doesn't care about technical decisions and I did not intend to
imply that he did. He should be judging what you present him based on
the value to the customers/users. Technical decisions are meaningless
in this context.
He does, however, care about cost. Which means that if you estimate a
big cost for a small value based on some technical thing the most
reasonable thing for him to do is de-prioritize it accordingly.