Ever feel like your projects are just endless to-do lists? 😅 Let’s flip the narrative. What if we started framing requirements as problems to solve, not tasks to complete? Trust me, it’s a game-changer!
Shifting Focus to the Customer
When we jot down tasks, we’re often laser-focused on the product. But who’s using that product? By framing requirements as problems, we naturally pivot towards the customer.
Think about it: when requirements are phrased as problems, both product managers and developers zero in on the user. The product manager (or product owner) is nudged to consider the who and why, not just the what and how. This means seeing the bigger picture—the customer’s job to be done (JTBD). It shifts the focus from just delivering features to delivering real value.
For developers, knowing the who and why behind a feature is like getting secret intel. 🕵️♂️ It provides valuable context that informs technical decisions. Plus, it allows them to make decisions themselves, speeding up development and boosting product quality. And let’s be honest, it feels good to know your work actually matters to someone!
Empowering Team Autonomy
Nobody likes being micromanaged or told exactly what to do. We all crave a bit of freedom and autonomy. By presenting developers with problems instead of tasks, we unleash their creativity and expertise.
Dan Pink nailed it when he said autonomy is a major human drive. Deciding how to solve a problem not only gives developers freedom but also taps into and enhances their mastery—their core technical craft. And guess what? Mastery is another big motivator!
When developers and product managers chat about the who and why, it boosts direct collaboration. No more playing email tag or deciphering cryptic Jira issues. It’s real people solving real problems together.
Read more about how autonomy and mastery motivate people in How to Motivate People
Breaking Free from Traditional Roles
In traditional projects, there’s often a Technical Project Manager (TPM) or Business Analyst (BA) acting as a go-between. They translate customer problems into technical tasks, and developers become task machines, often without a clue about the bigger picture.
But did you know: this approach stems from Tayloristic management, which wasn’t designed for knowledge work 😳. In fact, this approach has been shown to decrease productivity and stifle innovation among knowledge workers.
Plus, expecting a TPM to have deep technical and business expertise is a tall order. Even if they do possess this rare combination, they’re usually not actually implementing and thus are a level removed from what happens specifically in the tech of this product.
By shifting to agile requirements, we eliminate the need for this middleman. The product manager focuses on defining the problem clearly (the who, what, and why), freeing them from needing technical expertise. Meanwhile, developers—our highly paid tech experts—get to flex their problem-solving muscles. 💪 It’s a win-win!
Promoting Independent Requirements
Tasks can become a tangled web of dependencies—a bit like trying to play Jenga on a rollercoaster 🎢. We have to set up the database before we can implement the API, we need the API do implement the UI, and we need the UI in order to test it 😫
Framing requirements as independent problems however keeps things neat and manageable. The problem of getting notified of new books is relatively independent from solving the problem of filtering book reviews. Teams can tackle issues without stepping on each other’s toes, making the process smoother and more efficient.
Read more about dependencies in Why Managing Dependencies Is Dangerous And How To Do Better
The Magic of User Stories
Enter user stories, the unsung heroes of agile methodologies (hint: they’re an extreme programming technique, not a Scrum technique 😉). By describing requirements from the user’s perspective, they capture the who, what, and why without dictating the how. It’s like giving your developers a destination but letting them choose the best route.
This not only empowers the developers but also aligns everyone with the customer’s needs. It taps into the full power of a team of tech experts, leading to solutions that are often better than anyone initially imagined. 🚀
Learn about how to apply user stories in How to Boost Team Collaboration with User Stories – Not Just Writing!
Conclusion
Switching from task-based requirements to problem-focused ones isn’t just a tweak—it’s a transformation. It puts the customer front and center, empowers your team, and streamlines your agile workflow. Plus, it boosts motivation and job satisfaction among developers. Who wouldn’t want that?
Ready to experience this shift firsthand? Check out Agile Meadow, the newest game in my Agile Games Collection. It’s a fun way to grasp these concepts of agile vs traditional requirements and see them in action. 🎮
Stay agile, stay awesome! 😎
Thank you for reading The Agile Compass. I’m Matthias, here to help you help those around you become agile.
To get more, consider upgrading to a paid subscription. You’ll join our premium Discord community and get access to all past articles.
