Back in the old days, we used to write thick requirement documents. We would seek stakeholder approval and after that, design and coding kicked off. Months later, we would deliver our functionality. Unsurprisingly, this functionality often did not do what our users wanted. Requirements were misinterpreted, resulting in functionality they didn’t want. Or the world had changed, which made some requirements obsolete. Regardless, the product missed the mark by a long shot.
Since then, we adopted Agile approaches. Every iteration we assess if what we build is in line with stakeholders’ expectations. Then we plan to work on the next items from the backlog, ticking off the list. We still deliver our functionality from a predetermined list. We are still practicing Waterfall product delivery. Except now, we show what we’ve built before moving on. Which is slightly better than leaving them in the dark for months.
But it is still bad. This is still working based on unverified assumptions. Blood, sweat, and tears went into uncovering all the requirements, logging them, and prioritizing them. It feels wrong to write off all that effort, those sunk costs.
But when you don’t know what your best approach is to achieve your desired outcome with the product, you need to learn quickly and be prepared to adapt. You need feedback from your users and other stakeholders to verify your assumptions and understand what to do next.
A large backlog is an incentive to avoid looking for feedback. As you already have requirements which you even put in a certain order of priority. By planning based on the list of unverified requirements, you run a high risk of building the wrong thing. Without an effective feedback loop, you are crippling the potential value of your product.
Give your team a fighting chance — create an outcome-oriented goal and work with a light and small backlog. And adapt this backlog every iteration to optimize your chances to achieve your goal, taking into account the latest feedback and learnings.