Most of the technology partners implementing new solutions in the non-profit sector will now produce specifications that capture client requirements as User Stories. This is a departure from the traditional approach and, as may be expected, I have seen some misunderstanding about what this entails and some nervousness about how the functionality is described.
In my opinion, there are some real advantages to such an approach and the perceived lack of detail is not a barrier.
I would like to explain exactly what a User Story is, why this method is advantageous to your project, and why it can produce the perfect specification!
What is a User Story anyway?
A User Story is a non-technical, natural language description of a software feature, written from the perspective of an end-user or other stakeholder.
A simple way to think about it is, Who, What, Why. Who needs to do something? What do they need to do? Why do they need to do it?
A User Story is structured as a sentence that will read, “As a [WHO], I want to [WHAT], so that I can [WHY]”.
Take a couple of examples:
“As a Finance Manager [who], I need Invoices to be generated as a result of event bookings [what], so that the booking organisation is aware of what needs paying [why].”
“As an applicant [who], I need to be able to provide evidence against each assessment criteria [what], so that I can meet the requirements for full membership [why].”
But what is the advantage of expressing your requirements in this way?
Thinking outside the organisation [box!]
Let us first take another look at the first part of the User Story; the ‘Who’. It is this expression of different stakeholders, roles or personas that makes a User Story so powerful. This enables you to look beyond what you need to do your job and look instead at what your stakeholders want to do to interact with your organisation successfully.
I imagine your project includes an objective about better engagement with your stakeholders. User Stories allow you to put yourself in their shoes; who are they? What is their motivation and what do they want to do? And what is the outcome they expect?
Your specification should certainly include User Stories that state, for example,
“As a donor, I need to be able to set up a monthly donation…”, or
“As an applicant, I need to be able to upload my CV for review…”, or
“As a reviewer, I need to access applicant details and documents to review them or membership…”.
I do not believe that a list of functional requirements captures this in the same way; providing instead information about what you want your stakeholders to do, not the same thing at all.
Tech project vs. non-technical staff
Secondly, a User Story is completely non-technical; there is no reference to a CRM, and no reference to fields, tables, entities, buttons or even specific functionality.
There is no confusing language.
This means each User Story can be easily understood by the business teams across the organisation. No technical knowledge or understanding is required; each individual team member can relate a User Story directly to the work they do, or the actions a member, or donor needs to complete. Remember, your non-technical staff are the people that need to agree your specification.
Describing your needs, not your solution
Finally, it enables the analyst writing your specification to draft your requirements without having to consider how the system will work. There is no mention of what information may need to be captured or any business logic that may need to be applied to the function.
This is especially important as it gives you the confidence that your needs have been captured accurately, and you are not making compromises based on what a system can do out-of-the-box, or because of any preconceptions the development team may have.
When the development work begins, most likely at the start of each sprint, the detail behind each User Story will be described. Your partner will draft implementation notes that express the fields, data, logic and functionality in more depth. But this is a level of detail that is far too deep for your specification.
In my opinion, the use of User Stories to express your requirements is not something to be nervous about. A specification written in this way will provide reassurance that your business, and your stakeholder, needs have been captured effectively, and are easily understood by all parties.
This sets the foundations for a successful build.