Product Owner: Hey, how long do you believe Feature F will take? Developer: Idk. We haven’t even started working on it and it’s bound to stir up some old issues.
Estimates come in various disguises, but when you peek under the trench coat there is always the question:
"How long -- and using what amount of resources -- will be required to do X ?"
When I wear the developer hat, it can be infuriating to attempt to give an answer. It’s difficult to estimate (or the product owner could do it themselves) and a lot of the time it can be difficult to see why the estimate is even important.
When I wear the product owner hat, estimates are a crucial piece of the puzzle that must be laid in an attempt to plan the short and long term life cycle of a product.
In this post I want to attempt to explore and elaborate on both sides, in an attempt to make developers understand why estimates are important to product owners and in order to help product owners see why developers so often despise having to estimate their work.
Why the PO wants you to estimate
As a Product Owner (PO), I am responsible for learning the market and customers’ needs and translating these into feature requests which developers can turn into actual features in our products. The means varies, but most organisations have some sort of backlog in which things to be acted upon are placed while they await being picked up by some developer or development team. We call these things user stories, issues, tickets, tasks, and probably many other things… The important thing for this discussion is that the items in the backlog are candidates for being implemented in our product and it’s the PO’s job to prioritise the backlog.
Why does the backlog need to be prioritised?
Because the inflow of items to the backlog is (pretty much always) higher than the speed at which the developers can implement them. Ergo, if the PO does not constantly learn the market and customers’ needs and prioritise the backlog accordingly, the developers might implement features that the users of the product are not interested in. Worst case? Existing users stop using the product and no new users buy it which will ultimately lead to bankruptcy.
... continue reading