The Full Story

A friend recently pointed out an article that said that presentations are slowly pulling away from buzzwords & bullet points to be more engaging by telling the full story. This means that the audience is using a much more receptive part of their brain.
I was reminded of an old cartoon (strangely, I don't think it was Dilbert) where someone plays buzzword bingo during a presentation. That's about as exciting as it gets sometimes when someone presenting is simply throwing their viewpoint at the audience to either justify their existence, or else prove how clever they are. I'm not saying that consultants are the main culprits...

This is in line with how software development has been moving from requirements that read like bullet points ("name entry field must be twenty characters") to use cases ("the user enters their name; the entry screen validates the length; the database stores it in a field") to user stories ("as a user, I want to provide my full name, so that it is stored in the system"). Well written requirements are cutting out the "translation" steps from analysis to functional specs to design, etc, causing the developers to understand how the system really works with respect to the user, & ensuring that developers & testers are working to the same end goal throughout - they're using more of their brain.

Going back to presentations as a story - if you have a mixed audience, you tend to either dumb down the bullet points to the lowest level, or else ignore that sector & pitch directly at the money men. Telling a complete story (the old-fashioned way) means weaving into context the ideas that you want to get across, & also taking non-verbal feedback from your audience (fidgeting, worried expressions) to change gears & ensure that your ideas sink in.
It used to be accepted that only ten percent of a presentation (or a university lecture) is actually remembered. Why is this acceptable? Why waste your time giving the whole presentation when you could stop at the first yawn? If you engage your audience more, then maybe twenty percent will sink in - doubling your chance of a sale/investment/interest/support.

The same goes for software development. A two-hundred page spec written by a BA that gets translated into twenty different people's implementation of functions & tests is guaranteed to fail, because there is no consistency of interpretation. You cannot make a bullet-point spec so interesting that people will want to go back & re-read the fine detail, so they'll read once, hope that they have it clear in their head, & never go back to it - ninety percent loss of information.
A user story, however, relates to one piece of behaviour in a given context, clearly stated. Once that behaviour is correct, there is no going back to re-read, there is only (automated) regression testing.

User stories & TDD (test-driven development) or else BDD (behaviour-driven dev) speak directly to the BA's audience. Of course, the best way to do this is within an environment that fosters co-operation, so I do mean an agile methodology.

Hereafter, the person telling the story is not an external consultant proving how clever they are, but a part of the team who all want to know what the full story is.