Can you build me something that does A, B, and C for Users X and Y and have it completed within the next couple of weeks
What is the problem with this form of requirement? Many of you might start with the obvious that you need more details around A, B, and C to gain a shared understanding with the product owner or stakeholder of their requirements. Then, some of you will focus on "couple of weeks" and recognize that the product owner is trying to fix both scope and timeline which needs to be managed, ideally through agile estimation and prioritization. Others will also guess that the team already has a backlog and this requirement is probably an Epic that needs to be prioritized and planned for a release.
But this is not my fundamental problem with this form of my requirement.
What Problem or Opportunity Are You Solving for and Why?
The problem I have with the requirement is it's asking the development team to implement a specific solution. There's no statement of the problem, opportunity, or value that will help Users X and Y. The product owner has effectively decided on a solution and is only asking his or her technologists to go out and implement it.
I listed this issue on my 20 Bad Behaviors of Agile Development Product Owners and if I ranked them, #5 Defines solutions, can't state the business problem would be one of my top bad behaviors. For some product owners, they struggle with the effort and discipline required in separating problem from solution and collaborating with their development team on them.
I should point out that best practices in agile story writing usually starts with defining it from a user's perspective. As User X, I want to be able to do A, B, and C so that I can enjoy benefits Z. Also, agile coaches will help teams define product visions and release targets to better express and align on business value.
So there are mechanics in the agile process at the Vision (macro) and Story (micro) level but the issue as I'm describing it is more of a culture and collaboration problem.
Getting a Business Problem or Opportunity Defined
One reason getting the business problem or opportunity defined is that it can be harder to abstract especially when the Product Owner has to get feedback from customers or sales. It's easier for them to validate if A, B, and C meet customers' needs and a much more difficult dialogue to get at the real opportunity and value captured.
Therein lies a simple solution to this issue. If the Product Owner Thinks the Dev Team should only be consulted once the product is defined (bad behavior #6) then it's too late. They brought the team in too late and the product owner has already developed a strong opinion on a solution. Developers often have to back pedal there way to discuss alternatives, quality requirements, architecture considerations, and cost constraints.
Here is my advice
- Bring the dev team earlier
- Let some of them hear directly the voice of the customer.
- Draft the business problem together
- Partner with them on solutions
- Formulate a statement on quality objectives
- Consider multiple solutions
- Prototype and test with customers