Preface
This article is not about backlog management. It’s not about role definition. It’s simply about developing products efficiently and keeping Product Owners sane.
You will also notice that it is very much targeting the relationship between Developers and Product Owners. The same principles apply to other stakeholders likewise.
My Backlog!
A product backlog is a living entity. It changes constantly, and it evolves alongside the product and its needs.
The Product Owner is the person responsible for making changes to the backlog and for planning sprints.
Given the dynamic nature of a backlog, developers, who are at the forefront of this changing landscape, might want to add or remove user stories as new needs arise. It is especially true with technical chores, necessary refactors, and small details that a developer with a keen eye for details will spot.
While the intention is nothing but honorable, developers making changes to the backlog, or even worse, the ongoing sprint, create challenging situations for Product Owners.
Note that, in this post, “changes” encompass both adding and removing backlog items (user stories, bugs, or chores) from the backlog.
Why Having an Owner?
Having an owner goes along the same line as having a single point of contact (among other things). If more than one person makes changes, then no one knows what’s going on.
It is an all-or-nothing kind of situation. Either one person creates the development plan for the team, and the product development can move forward, or everyone creates the development plan, and it’s chaos.
I am not advocating dictatorship. Defining the backlog and the overall plan is a collaborative exercise with a lot of stakeholders involved. However, there must be one person and one person only —the Product Owner— who’s creating the actual implementation plan to avoid a chaotic situation.
Impact of Making Unannounced Changes to the Backlog
To build a product, a Product Owner wants to know at all times:
- What the team is currently building (the ongoing sprint),
- The sprint progress,
- If there are any blockers, issues, or bottlenecks,
- Whether or not the development team can achieve the sprint goals.
If someone other than the Product Owner (PO) makes changes to the backlog and the sprint, then the PO no longer knows the status for each one of the points listed above with certainty.
Making unannounced changes will alter what the team was scheduled to build, and the PO won’t know what the team is currently building. Developers would end up working on unexpected items. It will also distort the sprint progress leaving the PO with incorrect information. The sprint will either slow down because new items were added or speed up because items were removed but missing the sprint goals.
This lack of visibility can lead to implementing the wrong priorities or developing the right features but outside the announced timeframe.
Product development is not about exact delivery dates, but stakeholders management does require communicating dates. The Product Owner needs clear visibility on all the points above to give the development team enough flexibility while committing to certain milestones with stakeholders (e.g., a marketing campaign for a feature launch).
Stakeholders and Expectations
Product Owners have to get the product built, and they also have to inform and report to other stakeholders.
Picture the rest of the conversation in the following scenarios.
Scenario: a developer innocently removed the chore for setting up the email routing service because, on this e-commerce project, orders haven’t been implemented yet. We need to build products management and cart first, so it’s a low priority. While the PM hasn’t tested the feature just yet, he knows that it has already been completed:
- Stakeholder: “Is the user account creation completed already?”
- PO: “Yep!”
- Stakeholder: “Cool, let’s see it.”
PO demonstrates creating a new account:
Scenario: a developer found a “small” issue, decided to add it to the sprint then prioritized to work on it to quickly resolve it —to the detriment of the tasks actually planned— and found themselves in a rabbit hole taking a whole day:
- Stakeholder: “Are we on track to accomplish everything we set out to do this sprint?”
- PO: “We sure are!”
- Stakeholder: “Great, I will confirm the mass marketing campaign with the Product Marketing team.”
The PO at the end of the sprint:
Dos and Don’ts
If you are not the Product Owner, consider the following if you’re thinking about making changes to the backlog.
- Do not add user stories/chores/bugs in the sprint. Create the user stories/chores/bugs in the backlog and do ask the PO if that extra thing you feel is necessary can fit in the current sprint.
- Do not remove user stories/chores/bugs from the backlog. Do ask the PO if it will cause collateral damage to pull that one thing you don’t think is a priority.
- Do not mark a story as complete. Do nag the PO asking them to test and verify that the story can be considered done 😝
Epilogue
I’ve heard countless stories where Product Owners and Developers were at war or at least disliking working together. It doesn’t have to be the case. It shouldn’t be the case.
The backlog ownership topic isn’t to “show who’s the boss.” The Product Owner is not the Developers’ boss. The Product Owner, however, is accountable for the product delivery and is required to provide answers. Without this clear backlog ownership, the PO can’t work efficiently and with peace of mind. A developer changing the backlog without discussions with the Product Owner will actually create more tensions than benefits.
Developers and Product Owners can undoubtedly work in harmony. Communication and understanding how the backlog is viewed by all is the key.