Why Insist on User Stories?

I'm a programmer at heart and in an effort to make the most effective contribution that I can, I've found myself in a Product Management role. As a programmer in this role one thing I have great compassion for is the difference in the what us programmers know (or maybe think) are the highest priority and what is the highest priority to the end-user Product Manager/Owner customer.

Sometimes, especially very early in the development cycle, creating user stories can be challenging. It is easier to put programmer-oriented tasks into the backlog for our upcoming sprint. For example, as programmers we know we need to build the encapsulated, extensible, and testable presentation layer framework (e.g. MVP, passive view or other MVCesque) the communication and serialization framework (web services, REST, or RPC). Obviously these components are absolutely necessary in order to deliver the most essential customer features for our product and are the foundation of the product.

Of course we need that encapsulated and testable presentation layer. The efficient and extensible communication system is needed too. They are important. However, they are the means (implementation details) to the end (customer feature). As we design, build, and prioritize those means it is imperative that we always have the customer at the forefront of our mind. As we determine how extensible to make a class and how that decision impacts the orthogonality of the rest of the subsystem, it is invaluable to never be allowed to stop thinking about the feature or progress that we promised to deliver to our customer.

The point of going through the sometimes challenging process of breaking customer-oriented progress down into user stories is exemplified by a statement made by Alan Cooper:

Moving toward software components is a laudable thing. The problem is that the "componentization" is not based on giving users what they want; it's based on giving programmers what they want. What users want and what programmers want differ dramatically. What makes software easy for humans is not at all easy for programmers. Right now you have toolmakers out there who are creating extremely powerful sophisticated tools that serve programmers but not users.

On the more pragmatic side, another useful statement from Kent Beck is The way I explain it now is that stories don't have to represent business value to the customer team, but they do have to represent progress. Only the customer team knows what it will consider progress, so they have to do the slicing.