In summer 2020, I did a sailing and navigation course where the challenge was not to use GPS and an electronic chart plotter but to do it old school; paper charts, almanacs, binoculars, compass, trip log, and log. For those not familiar with nautical navigation, it is all about situational awareness. During the course, it became very clear that you always have to know where you are before you can decide where to go. Knowing where you are with GPS is simple, but when trying to approach a harbor you have never been to, at 11 pm on a pitch dark night without using GPS, knowing where you are can be a challenge. You need to match what you see outside, which is not much, with the paper chart inside the cabin to determine your position. And often, when it is most important (strong winds, rough sea state, difficult situations) it is more difficult to do (take a bearing with a hand compass on a violently moving boat) and there is less time to do it. At sea, the only viable option is to maintain situational awareness at all times and to be prepared when the shit hits the fan. What does this have to do with user stories?
Situational awareness
As PO I constantly try to make sense of my backlog and determine the course of the coming sprints. The rhythm of sprints can be comforting and finishing your planned backlog items feel rewarding. Each iteration you adjust your course, things are going fine, so it seems.
- Conscience: But what about your situational awareness? What about the user story from 8 sprints ago?
- Me: What do you mean? We finished it on time, it is in production and I did not hear any complaints.
- Conscience: Can you give me a list of user stories currently in production and tell me their current business value?
- Me: Shit, I would have to plow through all past backlog items in JIRA and be aware of subsequent changes. It would be a hell of a job. What their current value is, I do not have a clue.
- Conscience: So you’re setting out a course, but you do not have a clue where you are.
- Me: Shut up. Let me get on with grooming my backlog. Management wants to know what we deliver next quarter.
Maintaining situational awareness related to your product is always hard work. It will certainly not help if the tools you use and the way of working do not align with the wish to maintain this awareness. Hence the question; is a user story a requirement or a backlog item, a piece of work?
Let’s simplify things for argument’s sake. Let’s assume a product has two dimensions; what and how, and the what is represented by a list of user stories and the how by a set of source code files. Let’s consider managing source code as we do backlog items? How would that look like? You create a new JIRA Issue Type: Code. You create a new Code item: change file XYZ, replace lines 11 thru 15 with the following ….
Why will everybody understand the absurdity of managing source code this way, we blindly apply this method to user stories (or features, functions, requirements, whatever you would like to call them). The answer is that with source code we have to maintain state. We found out that not managing state simply does not scale. There is a technical necessity. Without it, we simply can not deliver fast, repeatedly, and reliable.
However, for ideas, product functions, features, use cases, user stories, requirements, there is no technical necessity to maintain their state. Technically we implement a new feature in code and maybe ‘forget’ about it. However, from a business and support perspective, we should maintain state. If we would create an IT4IT domain model and a user story is an entity, should represent state or change? I opt for the first and it should have a version, just as source code.
How did we get here?
In a past world of projects and waterfall, big upfront specifications were made including requirements. In some cases, special requirement management tools were used to go from stakeholder requirements to system requirements, or even to component requirements. In cases where such a tool was used, there was a need for structure and traceability, maybe a division into functional and non-functional requirements. Once the project was finished and the product delivered, the requirements were often neglected. At some point in time use cases were adopted as a way to specify functional requirements, then these were formalized to death such that people started to dislike them. User stories were introduced as an alternative for use cases. In the meantime ‘agile’ was introduced which is interpreted by many people as; we do not need to maintain requirements, designs, and other annoying things that distract us from writing code.
Product management; maintaining product state vs managing product change
The case of user stories is just one example where IMHO, where managing transition/change takes precedence and maintaining product state, is forgotten. Going back to my analogy this would mean setting out a course while not exactly knowing your current position (of course product position is much more complex than a coordinate). When the initial user story was implemented a long time ago there is a big chance that code changes have affected the current behavior and the intentions and motivations are lost in a sea of subsequent changes.
More seriously is the fact that if we have lost an overview of the intended added values (features) of our product(s), it becomes probably harder to measure the factual added value by seeking and receiving feedback on value delivered by customers.
This all can easily lead to the build trap described by Melissa Perri (Escaping the build trap; How effective product management creates real value). I have seen only a few products where a feature has been removed accompanied with clear communication that only a very low percentage of customers used the feature and the vendor has made a conscious decision to drop it.
Requirements as code?
So what is the solution? Managing product state requires baselines/versions to be defined. So maybe the best solution from the perspective is to have requirements as code. However, this has its problems, eloquently described in Write requirements in code, which is a discussion in its own right.
Conclusion
So let’s be honest, backlog management and requirement management are two different things. Backlog management is managing change requests. Requirements management is managing baselines (state) of all product requirements at a given time.
Is this bad? No, not if you want to manage change and as long as you are aware that you are not managing requirements. Yes, if you want to manage product state, including the product requirements, and you do not have the proper tools to do so, while management is convinced that you do have the proper tool.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
