Remember the Connextra Template (As a/I Want/So That)? It’s not supposed to be just a subdivision of a product feature spec. Really. I read an article called Common Misconceptions about User Stories by Antony Marcano, and this really rang true with me.
User Stories are where the user gets to express their need for change. What do they want to do, and why? Once we know that, we can innovate to propose a solution.
Some years ago my previous employer allocated a chunk of development effort to enhance the Purchase Ledger function. We already didn’t work with departmental budgets so a small overrun would not be a problem. The Purchase Ledger Manager was told that she had this allocation and invited to a workshop, along with her supervisors. At the workshop, they presented a long list of detailed designs where they wanted columns added to reports, faster screen responses and additional automation functionality. In the sense of being engaged Product Owners, it was fantastic! They had spent many hours thinking about their pain points, ways to reduce effort and ways to speed their progress. While we worked on their projects, they came and sat with the development team to do their day job of supervising a large department so that they could be instantly available to give feedback and guidance. But as for allowing us to innovate, it was rubbish. They didn’t expect us to analyze or think laterally at all.
So once we have the User Story, we need to do things like the Five Whys from Lean.
The Five Whys
- Why do you need that?
- Why is <<answer from first Why>>?
- Why do you <<answer from second Why>>?
- And so on.
When we start to think like this, we often discover that the obvious solution is not the most effective.
Take this example:
As a car driver I Want the windows in my car to open So That I don’t get too hot in summer.
Yes, it would solve the user’s problem, but in modern cars with very low drag coefficients, it’s cheaper over the life of the car to have air conditioning because the drag caused by having the windows open costs a considerable amount of fuel at highway speeds. The aircon option is vastly preferable to having the noise of an open window, and more than that it can provide temperatures unattainable by the window solution. The user in this example proposed a workable solution, but an informed analyst could have supplied a higher performing solution for a similar whole life cost.
So, what I did back there at my previous employer was to visit my user at her desk, and discuss the issues right there. This is called a Gemba visit (from The Toyota Way). Gemba is “the place where the work is done”. Not in a meeting room! I could get a conversation going and explore possible solutions with her on the spot and get instant feedback. We could agree the way forward in half an hour, not weeks.
Does this sound like Business Analysis 101 to you?
Would your users want you in their work area, or prefer to meet in a meeting room? I feel that there is no need for a business analysis framework or methodology in my world. We didn’t have Business Analyst or Tester job titles at that site, just Developers.
We did these things before learning Agile. “Agile” isn’t new or special. It’s just common sense.