One day I was reviewing a list screen in the development den and hit a brick wall. The application queue page had been developed by the senior architect of the team, a bearded philosopher type who had deeply absorbed the agile mantra to ‘maximize the amount of work not done.’ For this fellow, the answer was automatically ‘no’ until you made your case. I’m sure you’ve met one or two of these in your travels.
The screen in question was a list of transactions and they had some common attributes. That is, multiple lines could have the same description or the same type. Anxious to make what I thought was an easy improvement, I suggested that we add a ‘Row’ or ‘Item’ number column – something that the user could click on to open that row. The architect insisted that any other column could be used for that. A new column was not needed. The identifier column was indeed added to the list, but not that day. That day I left the room with hurt feelings and an important lesson in hand.
I failed to make the case for the new column. The change seemed logical to me (and, in fact, was) but I approached the feature based on my own desire and experience rather than bringing the team a value-based User Story that carried the weight of a real stakeholder. It is a lesson I would repeat until I fully embraced the principle that development team members are not application stakeholders. Only the voice of a real customer carries authority in a feature User Story.