From the Scrum Guide: “A Product Owner orders the work for a complex problem into a Product Backlog.”
Ordering work…
From Cambridge Dictionary: “order: a request to make, supply, or deliver food or goods.”
Not the usual use of the word when referred to in Scrum…
Quite a few questions come to mind when I think about this.
Order to whom?
To the Scrum Team—specifically to the Developers who are part of it. But can they say “no” to a Product Owner’s request? Absolutely—if the work is too large for a Sprint, if the team doesn’t currently have the necessary skills, or if the work doesn’t seem to add value. These situations should lead to open, constructive conversations among the Scrum Team about priorities, feasibility, and the value being delivered.
An order typically involves a cost.
Whether it’s money, time, or effort, every order has a cost. What is the Product Owner willing to pay? How much time does she expect the team to spend on this? What does the team estimate it will take to fulfill this request? Are they aligned on these expectations?
Unlike traditional management, ‘ordering’ in Scrum isn’t about giving commands. It’s about creating clarity and alignment within the Scrum Team on what to deliver and why.
To me, this idea of “ordering work” highlights the critical need for a shared understanding about the product and the work involved among all members of the Scrum Team. Ordering isn’t about control—it’s about creating clarity and alignment.
What do you think? How do you approach “ordering” in your Scrum practice? I’d love to hear your thoughts in the comments below!
PS. In a future blog post, I’ll return to “ordering” from the perspective of “arranging a group of things in a list from first to last.”
I hope you find value in these short articles and if you are looking for more clarifications, feel free to take contact.
Don't want to miss any of these blog posts? Have the “The Scrum Guide Explored” series weekly in your mailbox.
Wishing you an inspiring read and a wonderful journey.
Scrum on!
