Hacker News Reader

Hacker News

Comment by aard | Hacker News Reader

Parent Full thread

aard

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.

View on HN

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

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.

Reply on news.ycombinator.com