3 ms·

>In Scrum, Product Owners have sole authority over the Product Backlog; That first sentence was enough to stop reading

aard 2y ago
Isn't that pretty much textbook Scrum? The language in the Scrum Guide couldn't be much clearer... "The Product Owner is also accountable for effective Product Backlog management, which includes: - Developing and explicitly communicating the Product Goal; - Creating and clearly communicating Product Backlog items; - Ordering Product Backlog items; and, - Ensuring that the Product Backlog is transparent, visible and understood. " And if that wasn't enough... “…the entire organization must respect their decisions.” “The Product Owner is one person, not a committee.” “Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.” Sounds like "sole authority" to me.
- michaeljx 2y ago
  That's for people outside the Scrum team, meaning that no external stakeholder may manipulate the backlog by bypassing the POs. Internally the team must act as a cohesive unit, which means that a Scrum dev should have the same objectives as a PO, with regards to both priorities and goals. That may mean adding items in the backlog pertaining to technical debt, and so forth
- pan69 2y ago
  Thank you for listing out the cancer that is Scrum. Anecdotal story: Are product owners engineers? Typically not, and this is where the problem starts for most engineering teams doing "Scrum". I work with overzealous POs (who aren't engineers) and since they "own" the product and the backlog (as according to that definition), they own everything. Since the PO is supposed to manage the backlog, we have POs running backlog refinement sessions where the vast majority of topics and tickets being discussed are of an engineering/technical nature (lots of stuff that is periphery to the product features such as security enhancements, build pipelines, performance, code quality and tests, etc.) and since the PO "owns" it all it is their decision/opinion what counts, i.e. they pretend to be tech-leads. I even work with a PO who insists of writing all the engineering tickets (title/description), where no engineer can understand what the ticket is about since this person simply doesn't have the ability to clearly and concisely articulate engineering tasks. Now, obviously people will point out that this is not a problem with Scrum but a culture issue with the organisation, and I agree (my organisation has many ingrained and deeply embedded institutional dysfunctions) but the Scrum definitions aren't helping engineering teams.
lucisferre 2y ago
As much as this comes across as an obvious strawman, it is also consistent with Scrum in practice. Scrum proponents constantly suffer from the "no true Scotsman" fallacy exactly because in practice Scrum inevitably resembles it's own strawman.

aard 2y ago

Isn't that pretty much textbook Scrum? The language in the Scrum Guide couldn't be much clearer... "The Product Owner is also accountable for effective Product Backlog management, which includes: - Developing and explicitly communicating the Product Goal; - Creating and clearly communicating Product Backlog items; - Ordering Product Backlog items; and, - Ensuring that the Product Backlog is transparent, visible and understood. " And if that wasn't enough... “…the entire organization must respect their decisions.” “The Product Owner is one person, not a committee.” “Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.” Sounds like "sole authority" to me.

michaeljx 2y ago
That's for people outside the Scrum team, meaning that no external stakeholder may manipulate the backlog by bypassing the POs. Internally the team must act as a cohesive unit, which means that a Scrum dev should have the same objectives as a PO, with regards to both priorities and goals. That may mean adding items in the backlog pertaining to technical debt, and so forth
pan69 2y ago
Thank you for listing out the cancer that is Scrum. Anecdotal story: Are product owners engineers? Typically not, and this is where the problem starts for most engineering teams doing "Scrum". I work with overzealous POs (who aren't engineers) and since they "own" the product and the backlog (as according to that definition), they own everything. Since the PO is supposed to manage the backlog, we have POs running backlog refinement sessions where the vast majority of topics and tickets being discussed are of an engineering/technical nature (lots of stuff that is periphery to the product features such as security enhancements, build pipelines, performance, code quality and tests, etc.) and since the PO "owns" it all it is their decision/opinion what counts, i.e. they pretend to be tech-leads. I even work with a PO who insists of writing all the engineering tickets (title/description), where no engineer can understand what the ticket is about since this person simply doesn't have the ability to clearly and concisely articulate engineering tasks. Now, obviously people will point out that this is not a problem with Scrum but a culture issue with the organisation, and I agree (my organisation has many ingrained and deeply embedded institutional dysfunctions) but the Scrum definitions aren't helping engineering teams.

lucisferre 2y ago

As much as this comes across as an obvious strawman, it is also consistent with Scrum in practice. Scrum proponents constantly suffer from the "no true Scotsman" fallacy exactly because in practice Scrum inevitably resembles it's own strawman.