Several projects on a digital transformation journey decide to switch over to user stories rather than requirements (overnight). The decision seems to have been made by certain managers who want to show progress that they are moving towards digital.
While arguments can be made why and how the migration should happen, to cut the chase short, it is not a clever idea unless you bring in the whole nine yards – there are other Agile elements that need to go along with the user stories. Aspects like culture, training, ceremonies, practices, yada, yada, and yada…
While to user story or not is a topic of discussion, in today’s piece, I intend to showcase user story as a knight in shining armor for projects that are dynamic, flexible and stay in close collaboration with users and stakeholders. I didn’t use the word Agile intentionally because all the adjectives I was using were pointing towards Agile projects.
What is a Requirement?
Requirements define what a product should have – functionally, aesthetically, and technically. The level of details will tend to vary between requirement documents, but the requirements revolve around the product.
The idea of writing a requirement document is to ensure that everything that you want in a product has to be documented, so the developers can weigh in on all the aspects as they start to develop. Changing the requirements during the development phase is frowned upon as it could entail rework and redesign of the overall project plan.
If I am a product manager for a pen, then my requirements would sound like:
- The pen must be of fountain type and must leverage on generic cartridges
- The nib should be fine
- The diameter of the pen at its widest point must not exceed 150mm
- The length of the pen must be between 10cm and 12cm
- The pen must be available in all rainbow colors
As a pen architect, I would know exactly what I am building, and my designs would be in line with the requirements and manufacturer undoubtedly would stick to the design.
Let’s see how a user story will sound.
Now User Story
While the requirement sweated around the product, the user story is like a day in Hawaiin party where everybody is free to roam about dancing, drinking, and enjoying without giving a hoot about what the world would think of them. In other words, a user story is personal. There’s a personal touch to it.
It’s not about a product. Although you are laying out the requirements for a product, a user story tells you what the end user wants to do with it.
The pen that was designed in the earlier section was all about the pen, and never about the user. What does the user want? That question was never answered. If the same requirement for a pen was to be laid out as a user story, it may sound like this.
As a writer, I want a fountain pen that is a pleasure to hold onto – not too heavy and not too light. The bottom and the top should balance so when the writer writes, he/she does not feel the fatigue due to the weight of the pen dragging down. It should write smooth and bold. And as a writer, it is important that the pen looks shiny and attractive and must be a highlight when carried around.
How differently a pen’s requirement was drawn out in a user story! There was no mention of the length or breadth specifics, no ink feeding mechanisms and none of the jargons. It was all about what the user wanted, and what the user desired.
Does it mean that the specifics are not to be thought of? Read on…
User Story vs Requirement
A requirement defines and describes the functionalities and technicalities that go into making of a product – which is very much needed if you are building a product. A well-defined requirement is lauded for the clarity it brings to the table and the ease at which the developers sense the need and fill the void.
A user story on the other hand describes the same product from a distinct perspective – from the perspective of a user. It describes, not so much in detail, on what the user intends to do with the product. However, there are several blanks that are left to be filled. Without knowing the full story, how are the developers going to build the product?
The answer and the underlying difference between a requirement and a user story lie in the timeline. From the time a requirement document is drawn, and the product is developed, we have to believe that it will not be a matter of days or weeks, but rather months and years. By the time the product comes off the mint, the needs of the product’s users would probably have changed. Remember that the digital age runs at an accelerated mode. A digital product such as a software cannot be compared with a non-digital product such as a villa. A villa can withstand the rigors of time but not a piece of software. Hell, I stay in an apartment that’s at least fifty years old and I have no qualms. Imagine using Windows 3.1 today – would you have the same experience as an apartment. So, it is important that the digital product keeps its ears to the ground and what gets churned out is fairly latest and not antiquated.
A requirement document that takes eons to build and the product takes multiple eons to develop is more often than not is going to disappoint the intended user. It’s like a cellphone service provider offering 3G services today. Today we are leaping into 5G and a 3G network is not going to raise any eyebrows mate!
A user story on the other hand drawn broad brush strokes on what the user intends to have. Nothing is set in stone. New features are churned out based on the user’s feeling and since nothing is pre-decided, moving from one requirement to another at the drop of a hat is easy, hassle-free and most importantly practical and profitable for the business. The best part is that you don’t even have to perfect a feature to release it, just develop a bit, test it and let the users use it. The next half of the feature can come out next week or the week after. It doesn’t matter. The user keeps getting something new every so often that he does not feel like he is stuck in the past.
User story’s biggest advantage is its flexibility. It’s ambiguity gives multiple degrees of freedom to fill the dots. In iterations, the developers can start drawing one feature at a time, or in cases, a fraction of a feature as well. In reality, the complete product will never be fully formed as the user’s keep coming up with something new to be retrofitted into the product and they keep the prdouct ever so alive. Take for example any digital product that you see today, none of it is short of features and with every release, there are new features that nobody would have thought have one year back. It’s like these features were picked from thin air and they make the product so wonderful to use.
