March 30, 2023, by Gabriele Giaccari
"How long does it take? How much is it?"
The fateful question, every programmer's nightmare. An obligatory punishment to expiate at the beginning of every new project, to always answer in a rather creative way and with unmotivated optimism. From this reply, indeed, numerous sufferings will originate, nights and week-ends of work, softwares full of unsuitable functions, emails from the lawyers of clients and managers.
For years I relied my answer in the 'dice technique'. Yes, at the office we had a big orange dice made of rubber: it was sufficient to throw this dice, read the result and add some zeros. But it wasn't really efficient.
Luckily, on the other side of the ocean there was somebody trying, since years, to solve this problem. For me too.
The methodologies that refer to the world of Lean and Agile have made it clear, that the reality around us is constantly changing and we are not able to foresee the future: it is therefore better to proceed with small incremental steps, checking each time the results obtained and adjusting our plan.
Although this approach already helps us greatly, those who set the budget will always continue to ask The Question. And with good reason, I'd say.
But it's thanks to the User Story Mapping that, for some years, even if with due approximations, I started to give answers that made sense.
In 2008 Jeff Patton, an american computer scientist/technician and product manager very active in the Lean / Agile panorama, publishes an article entitled "The New User Story Backlog is a Map".
He introduces a new technique, simple but extremely powerful, to define the roadmap to follow in the realization of a product / project, having clear the general framework and building that "Shared Understanding", fundamental to succeed.
What is it about?
All the people involved in the project must understand what they want to achieve, what needs to be done and with what priority: the overview of all the steps to reach our goal helps us enormously, among other things, to get an idea of how much, approximately, it could take.
The backlog therefore, the list of tasks (User Stories) to do, becomes two-dimensional and is extremely useful.
User Story Mapping is basically a conversation between those who have in mind the product to be made - let's say the customer - and who will have to realise it.
During this conversation we analyze all the steps, in logical order, that our ideal user will have to perform to achieve a certain goal. We have to remember therefore that the point of view of these 'stories' is precisely that of the user - hence the name User Stories - and itâ's not only interesting what he does, but also who he is and why he must or wants to perform a certain action. Only by knowing it thoroughly - thanks to methods like Customer Development, topic of the recent article by Mirko Maiorano - we'll be able to imagine his point of view.
For convenience, we note down these steps on sticky notes to remind us of them in the future, and we stick them on a wall or table, in order, so that reading them from left to right we can retrace the entire journey of the user: since he enters in contact with our product to when he gets the desired result.
Personally I wasn't a sticky notes lover, but I must admit that during these meetings they are very comfortable: you can move or change them, people indicate them, and all this wouldn't be possible on a monitor or a paper sheet. Obviously, in a second moment nobody forbids us to report everything on a software.
It's very important to point out that these notes, short sentences describing user behavior, are just 'promises of conversations', which we will then do in due course, when it will be necessary to analyze the details. They aren't 'requirements'.
To understand these promises thoroughly, before implementing them, we'll have to talk with those who imagined them or, even better, with those who have that need. Their position - and presence on the map - is always under discussion, and certainly over time, as we acquire new informations, the map will transform.
I make an example, taken up by Jeff himself.
Try mapping your morning routine: list all the actions, from when you open your eyes to when you go to work. And so you will turn off the alarm, prepare breakfast, take a shower, feed the cat, etc. etc. These actions, one after the other, will describe all the steps we typically take to reach the goal of leaving home. Focusing on the entire path, we'll have a clear view of the whole process, we will more easily see the 'holes', and we will make sure that we go into details only when necessary.
At this point the first doubts arise: what level of detail should we use to describe these tasks?
Is it enough to say that 'I take a shower', or do I have to list all the actions to be taken, opening water, soaping, putting shampoo, etc.? Or again, taking a shower is already too specific, is it enough to say generically 'I wash', including brushing your teeth, maybe shaving?
To answer this question, we can use a metaphor of Alistair Cockburn, related to the sea.
He divides the tasks into 3 types:
If some tasks are alternative ways to get the same 'goal', we put them one below the other: it will be, among other things, very useful to map the variants that respond to particular use cases. If instead we are undecided on the horizontal order between two, it is probably because it isn't so important (there are those who take coffee before the shower and who after).
Some critical points begin to show, but it's still a rather easy exercise. When we talk about structuring a software, things get a bit complicated, clearly, but the level of 'mental order' that is given to the project in this way is priceless.
My personal experience is that after a session of User Story Mapping - usually a lot of hours - customers come out of the door with a clarity and an awareness of what they want, never achieved before, even after months of long and complicated documents in pdf and technical requirements.
So we have this horizontal row of tasks to form a sort of backbone of our map, organized in activities, and below a series of tasks detailed descending in vertical lines.
We'll begin to realize how many things we have to do, how these are connected, and we can finally think about the optimization part: which are the essential ones?
Returning to our morning, let's imagine that the alarm did not sound: then we wake up by chance, look at the clock, and immediately realize the disaster. We have only 10 minutes to get out in time instead of an hour! We are therefore forced to choose only the truly essential tasks to achieve our goal: we renounce to the breakfast? And the shower?
This is how we should think when we think of our MVP: an accurate choice of the essential things to achieve a goal, as quickly as possible.
We don't need to yell at our programmers to tell them to do it quickly, with consequent lowering of quality. Patton says:
"Your job isn't to build more software faster: it's to maximize the outcome and impact you get from what you choose to build."
Let's trace a line, and keep only the tasks chosen for our MVP above it, moving under it all the others. We can repeat this choice also for following milestones, even if the more we delay this decision, the more chance we'll have to rethink everything, wasting less time now.
Remember, after all, that the choice of what is more or less important to do in the next release, it's still a bet - which we should possibly base on objective and measurable data - and never a certainty. Eric Ries (author of Lean Startup) says that a MVP is the smallest thing you could create or do to prove or disprove an assumption.
I add one last very practical consideration on this topic: to achieve a task goal and specifically implement a feature, there are always several alternative ways.
Our skill must be to identify the one that requires the least effort: if once the functionality implemented in the basic mode has been tested, we see that the users use it, we always have time to improve it, looking at the data of how it was used. If this doesn't happen, we have saved a lot of time avoiding to implement something useless.
To implement a payment on our site, for example, we can initially only ask our users to send us an email and manage it 'by hand' via a wire transfer. Only if someone actually will do it, it will be worth integrating an online payment system (starting with the most common one), supporting the lesser known ones later.
At this point we should have a clear idea of the structure of our project, great part of the things to do - something will always run away - and above all what to concentrate on first.
Estimating the various tasks that have arisen - however difficult and not forgetting that an estimate is by its nature inaccurate - therefore becomes a much more affordable operation. You can choose to be a little more precise for the first things to implement, and less for those likely to be more distant in time.
Estimating individual User Stories is a subject that goes beyond the intentions of this article. There are different techniques and units of measurement: I personally find the planning poker really effective. To deepen this discourse and the world of User Stories in general, I invite you to explore the topic with Mike Cohn, one of the professors, along with Jeff Patton and Eric Ries, which I wish I had had at the University. Maybe, in that case, I wouldn't throw orange dice in the office!
To deepen this technique the main resource is obviously the book by Jeff Patton, released in 2014, which is not just a technical manual on this specific practice, but a fundamental essay about products management.
Business and the strategic world - where the aforementioned methods come into play - of Customer Development, Lean Startup, or Design Thinking - meet the more 'practical' world of software development with Agile methodologies and tools like User Stories, thanks to these maps.
This, at least for me, represented the closing of the loop and the missing step to get from the initial idea to its realization, in a very logical and almost guided way.
Always keeping in mind the end and not the means: the map, the sticky notes, are only tools to reach the true goal, the shared understanding through better conversations that keep users at the center, and allow us to focus on targets and validate our hypotheses.
And now you just have to try and share your experience with me!
Ambitious products need innovative methodologies and practices.