Week 13 Day 1: The 'Why Does This Matter?' Question

This is the question your team is silently asking about half the work they do. They pick up a ticket, build the feature, close the PR -- and never understand why it mattered. Not because they are disengaged, but because nobody connected the work to the business outcome. The 'why does this matter?' question is not philosophical. It is operational. It is the bridge between the Value Pyramid you built in Week 11 and the daily work your team actually does.

Here is a test you can run right now. Open your team's current sprint board. Pick five tickets at random. For each one, try to complete this sentence: 'This work matters because it directly affects [revenue / margin / overhead] by [specific mechanism].' If you cannot complete that sentence for more than two of the five, your backlog has a clarity problem. I ran this exercise on my own board and found that three of my five sprint items had no traceable connection to any business outcome. They were there because someone asked for them, because they seemed important at the time, or because they had been sitting in the backlog long enough to feel overdue. None of those are business reasons. They are inertia reasons. The fix was simple but uncomfortable -- I deleted everything from the backlog that could not answer the question, and we rebuilt it from scratch using the Value Pyramid as the filter.

The 'why does this matter?' framework is a practical application of what Sinek (2009) popularized as 'Start With Why' and what Christensen (2003) formalized as 'jobs to be done' theory -- the idea that every successful activity serves a functional, emotional, or social purpose for the customer. In project management, the PRINCE2 methodology (Axelos, 2017) requires a 'business case' for every project that must be continuously validated throughout execution. The backlog pruning exercise described in level_2 maps to what Schwaber and Sutherland (2020) in the Scrum Guide call 'product backlog refinement' -- the ongoing activity of clarifying and reordering work items based on value. Research by Patton (2014) on user story mapping found that teams using value-based backlog ordering completed 35% more high-impact work per sprint than teams using urgency-based ordering, because the value framework provided a consistent decision criterion that prevented the backlog from being dominated by recency bias and loudest-voice dynamics.