Issue Driven Design... Anyone See The Problem?

Harder to follow Scrum — When Product and Sprint Goals are an afterthought, following the Scrum Guide feels artificial and forced. When teams feel forced to define a Sprint Goal, or a PO feels pressed to define Product Goals, the door is open to casting further doubt about the process.

Harder to keep the eye on the ball — deriving meaning from issues can make Product Owners and teams lose sight of their ultimate purpose. A Backlog dominated by user requests & feature ideas is short-term-minded and can distract you from pursuing your long-term vision, or may even repress the need to define a vision. Who needs a vision when the Backlog is full of planned features for years to come?

Harder for teams to achieve a high degree of collaboration — a collection of loosely related issues is not conducive to collaboration.

Encourages a feature-factory mindset— when productivity is measured by how many issues are done you can create an illusion of progress while the vision remains as distant as ever. Instead of “how many issues did we finish” and “how many features did we add”, ask “how many goals were achieved?”, and “are we getting visibly closer to the vision?”

Harder to collaborate with stakeholders — A Backlog full of short-term concerns leads to low-level discussion and understanding of the Product. Reviews feel ineffectual & less impactful as the Backlog doesn’t reflect the right level of concern and doesn’t offer meaningful choices. A review shouldn’t ask “what’s the next user request to implement?”, but rather “what’s the next goal to focus on?”.