4 ms·

> It's basically "give the product managing responsibility to engineers". It's really not going that far. It is critical of the notion that someone without sof

> It's basically "give the product managing responsibility to engineers". It's really not going that far. It is critical of the notion that someone without software engineering chops can dictate an appropriate ordering of sub-jobs. That's a legitimate position to take, and we observe it in practice regularly. It's also in a very specific context, Scrum, and it's talking about these rigidly defined roles. It doesn't really make sense to discuss it outside of this context, because Scrum puts itself in a precarious position. The #1 rule of Scrum, literally, is "A Product Owner orders the work for a complex problem into a Product Backlog." This is what the author is going after. And, there can be no absolutely no deviation, because "The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum."

stickfigure 2y ago
That sounds fine? The Pivotal process is equally rigid about the backlog order. But the important distinction - and if you've never worked with a Pivotal team you might not realize it - is that the pointed stories in the backlog are all customer-facing. They represent business priorities. The PM absolutely defines the business priorities. Pointed stories are not created in a vacuum; the PM works with the tech leads to define reasonable features. And pointing is done by the engineers. Also, nothing stops the eng team from adding (unpointed) chores to the backlog and working on them! But there's a velocity cost and that can affect delivery dates. There's negotiation involved. If the PM is micromanaging engineering tasks, you're doing it wrong. The process requires a good PM.
- Kinrany 2y ago
  Thr current Scrum guide also defines two separate backlogs: sprint and product.
jghn 2y ago
> It is critical of the notion that someone without software engineering chops can dictate an appropriate ordering of sub-jobs This is the exact issue. And people talk past it all the time. Product designs the specs for a set of changes & proposes a timeline. Engineering breaks that down, perhaps the two sides negotiate on the timeline. Beyond that, Product should generally stay out of the day to day. "I want sub-sub-sub-widget-X first" discussions are what lead to the tension that we see here.

stickfigure 2y ago

That sounds fine? The Pivotal process is equally rigid about the backlog order. But the important distinction - and if you've never worked with a Pivotal team you might not realize it - is that the pointed stories in the backlog are all customer-facing. They represent business priorities. The PM absolutely defines the business priorities. Pointed stories are not created in a vacuum; the PM works with the tech leads to define reasonable features. And pointing is done by the engineers. Also, nothing stops the eng team from adding (unpointed) chores to the backlog and working on them! But there's a velocity cost and that can affect delivery dates. There's negotiation involved. If the PM is micromanaging engineering tasks, you're doing it wrong. The process requires a good PM.

Kinrany 2y ago
Thr current Scrum guide also defines two separate backlogs: sprint and product.

jghn 2y ago

> It is critical of the notion that someone without software engineering chops can dictate an appropriate ordering of sub-jobs This is the exact issue. And people talk past it all the time. Product designs the specs for a set of changes & proposes a timeline. Engineering breaks that down, perhaps the two sides negotiate on the timeline. Beyond that, Product should generally stay out of the day to day. "I want sub-sub-sub-widget-X first" discussions are what lead to the tension that we see here.