Discussing User stories Vs. Executing HiPPO requirements

In the same way that Agile is more of a mindset, often reduced to a toolbox, “User stories” can be stripped of their essence and value. They become “user requirements” to be blindly delivered, somewhat “back-massaged” into user story format without discussion. A Word doc sitting on a shared folder of little value, that can even lure into a false sense of best practice. Hollowing out a holistic approach, into a dry and “rubber stamping” tool effectively justifying the old, prescriptive paradigm.

But we know user stories

That “revelation” came to me years ago, sitting with a client who was struggling to deliver user value. Their backers and VC were becoming agitated and frustration was high. 

Yet, they had great sprints planning, friendly pithy stand-ups, updated burn-down charts, talented devs, but the metrics feedback that kept coming back was underwhelming. These were lovely people, smart, hard-working, all fundamentals for high performance were there. 

And yet their user stories were terrible.

They were not stories at all. 

Senior stakeholders dictated “requirements” during the “backlog grooming” sessions, based on their intuition alone. No user story cards to trigger a conversation, let alone a confirmation. Staff would enter “user stories” in JIRA, without cross-functional fleshing out of what value exactly we were going to deliver, to whom, why, and how. 

They were (unconsciously; effectively) following the dreaded HiPPO approach, disguised as user stories. HiPPO stands for “Highest Paid Person Opinion” a common mistake first formulated by Adam Grant. It is tempting (or politically convenient) for many organisations to think that the “HiPPO” has the best individual opinion. Whilst that may often be the case, it is hardly the point. User stories, and Agile, draw a lot of their value from collective intelligence. No one can have all the best ideas, knowledge or view of all contingencies. Or know the user perfectly. And you cannot bounce ideas creatively with yourself.

And that weakness reverberated across their operations. User needs were not fully captured. Outputs were mistaken for outcomes. Valueless features were announced,  half-developed until killed. Others were scuppered unceremoniously when they ran aground on unseen contingencies.

In the end the solution was straight-forward. The founder agreed that user stories needed more collective engagement. We replaced the dreaded “backlog grooming” sessions with the dynamic, collegial, fun effort of a cross-functional team doing User Story Maps. Both efficiency and effectiveness (especially the latter) improved immediately.

Keep It Simple Stupid: It’s about communication

Picture courtesy of Jeff Patton and his brilliant, seminal book "User Story Mapping"

“Funny” thing is that here, we are talking about user stories that are not stories, and that are not discussed. 

The illusion of “discussion” came from the Word doc being hosted on a shared folder, I think, reinforcing the idea that it was a collaborative effort. 

Talk of hollowing out the essence of a tool… A bit like a surgeon who before the operation tells you “I just want you to know I could not discuss the operation with the nurse or with the anesthetist, BUT look I have modern tools I keep in a shared cabinet!1!!”

The irony becomes supreme in the sense that Kent Beck, who brought us the “user story” always insisted they absolutely needed to be discussed. In fact, Kent Beck regularly pointed out that communication was the single most important success factor in Software projects. 

When you say this to some PM’s you can see in real time, their eyes glaze over. They often smile meekly and say a quick, cursory “yeah yeah” to guide the conversation along, probably to something they consider less intangible / hippie / arty-farty (A GANTT chart made of largely imaginary estimates?)

The simple truth is that candid but caring, frequent, transparent, collective and rich communication is actually, massively important. And if intangible it translates to very real $.

The truth is, collectively, out there. 

My boss the excellent Steve Milburn, secretely happy to have found a big contingency so early on in the project

In most Agile teams there is, collectively, the perfect answer to the best design and software engineering. It may need teasing out, discussing and refining but it is, ironically “there”. It just needs to be externalised in a group, so it can be examined, refined, understood by all, and then delivered (awesomely by that stage). 

But if BA is reduced to a dry, prescriptive HiPPO requirement, without cross-functional engagement you will miss contingencies, and you will miss value delivery time and again (and drive you devs. insane).

Kent Beck after all, was the founder of XP (Extreme Programming) and he understood that the story format was the best, most brutally efficient and effective, to capture ideal outcomes,  dev. them into the best code delivering the most value the fastest. He understood before others in SDLC, that great communication was central to extreme efficiency and effectiveness.

He is not even that new on this one, ancient Greeks originally refined the art of dialectics, so they could take better military decisions (hardly a hippie endeavour). It was understood that different people sharing different opinions, claims and counter-claims allowed everyone to gradually come to a much more informed, much better decision making. 

Summary and solutions 

If we must stick to a quick, tangible approach (maybe the best place to start in prescriptive environments) then User Story Mapping will ensure that you develop better products, with a better fit to market, with less internal friction and less waste. I do not know a more 80/20 tool like that, and to start changing the worldview and culture around something very concrete.

If you can also take a look at the culture and the language, you can also gradually effect positive change, moving away from the illusion of a “hyper engineering”, autocratic world view. 

The way to capture user requirements best, requires empathy, patience, observation, and open-mindedness. It requires the communication knack of engaging as many relevant parties as possible in the refining of a user story so that it comes alive, and so the product becomes a breathing living thing. And so that valueless features are “chiseled out” of each sprint (even if they made some kind of sense in an engineery way).

UX has very little to do with an engineer’s planning, however brilliant it objectively is. A user is not interested in whether the software has technical debt or not. A user has little time and will not try to understand what the person who designed the website had in mind.