2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- November 10, 2021
- Say What, Why, and for Whom Before How
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy.
One of the most powerful and important aspects of user stories is the WHY clause. WHY a feature is wanted is often never mentioned in written requirements documents or specifications. This is one of the fundamental characteristics of Agile software development where we focus on the WHY so that we are clear on how to meet the needs of our users when we implement a feature.
When we know WHY our users want a feature, we can often build the feature to more directly address their needs. Building software requires making an endless set of decisions in order to build even a simple feature. Understanding the purpose of the feature helps us make those little decisions in the moment more accurately.
But there’s another reason that knowing WHY a feature is wanted is so critical when we’re building it, and that is that it connects all of us to the purpose of building what we’re building in the first place and this helps give meaning to what we do.
If Maslow was right and after our physical needs like food and shelter are taken care of and we begin to start to give back to others and want to make meaningful contributions, then knowing WHY we’re doing what we’re doing can help us on the road to personal fulfillment.
I know some managers who insist that is pointless for developers to know why features are wanted by a user. In their minds, developers should just do what they’re told and that it is even possible to accurately tell someone exactly what to build in a feature, but I don’t think this is always the case.
I don’t want to think about professional software developers as people who simply implement a specification. There’re many aspects to software development that require vastly different skill sets. Some developers are really good about thinking from the user’s perspective. Others are good in terms of thinking about how to implement complex algorithms and still, others might focus on performance.
All of these things are important, but we tend to weigh the importance differently and sometimes we don’t always come to agreements because of it. Knowing the WHY can oftentimes clear up ambiguities and help us build features that are more consistent and on point for what the user wants.
I personally believe that the more a developer knows about WHY a feature is wanted the more the developer can address that need because if the development team isn’t addressing the needs of the user, then they are not being addressed.
Oftentimes, it’s the Product Owner or customer representative that stands in for the user and acts as their proxy. If that individual, and it’s usually best if it is an individual rather than a committee, understands WHY the feature is wanted then she will be able to craft solutions that are more valuable to users.
Previous Post: « Personify the Who of Stories
Next Post: Start Simple then Enhance »