A CRM implementation must be a comprehensive, cross-department process involving:
Though the above list is a useful guide as to what order of priority you should follow, addressing this list in reverse order here helps clarify some of the rationale as to why.
One of the first challenges in software development is gathering clear requirements and keeping them unchanged during the implementation. Requirements documents can be lengthy and too technical.
At Crust, we implemented user stories as part of our project management and business analysis process and we acknowledged that this is a powerful way of defining the required functionalities from a user’s point of view. They reflect what a particular user needs and what value is gained from using ‘plain English’ without technicalities and implementation details.
A typical user story template looks like this:
As a [role], I want to [requirement] so that [benefit].
The role describes who is going to benefit from the feature. We want it to be more specific than “the user” so consequently, the first step in the process is to successfully identify all types of users involved as end consumers. In our case, these are usually, but not limited to, “CRM admins” with administrator privileges and “CRM users” with restricted access.
The requirement part briefly describes what the user wants to accomplish. The story shouldn’t be specified in too much detail and it has to reveal the perspective of the user who will benefit from the function, not the developer who will be coding it. We also try to avoid using technical terminology (e.g. we might write “I want to remember my login details” instead of “I want to store my login credentials into a cookie”.)
The benefit states why the user wants this feature and what value it brings. This part helps product owners to better prioritize the requirement and gives the development team more freedom to find innovative ways of implementation to solve the objective. If the benefit can’t be articulated, it might be a good sign the feature is not necessary.
I recommend checking out INVEST technique to validate if you’re writing efficient user stories:
From our experience, this approach empowers product discussions along with the product development team and external stakeholders. Writing user stories often saves us time as it helps us to define high-level CRM requirements without necessarily going into too many details too early. It gives us cross-team clarity on what matters most to the user – what do we need to build, for whom exactly, why and what’s the priority.
User stories are easy to define and understand so they became a standard way to summarize the functionality by both technical and non-technical team members. Instead of confusing specifications with complex terminology, we provide our clients with a requirements list that they can understand and with which they can identify. If you want to encourage the participation of non-technical team members, why not give user stories a try?
