How do we make requirements gathering easier? Let users tell the story
“The only thing that is constant is change.” – Heraclitus
Change is constant and software requirements change constantly. Gone are the days when people sat around with their laptops and printers and got busy wasting time on setting requirements in stone. Thanks to Agile methodology, regular scrums ensure progress towards deliverables that are released on schedule in sprints, without burning out your team with overwhelming business jargon and turning them into gears in the assembly line.
So how do we make requirements gathering easier? By telling a story – clearly and concisely – that comes directly from the users.
Users are the best sources of requirements. Sure, stakeholders and decision makers can give their inputs and spend time debating what’s right and what’s wrong but, at the end of the day, they are not the ones who will use the software. Numerous technology projects fail because users are not involved in the project or, if they are, they join during the last part of the project as acceptance testers.
Telling your Requirements Like a Story
Unlike traditional requirements gathering, which involves creating lots of documents containing needs and wants, user stories start with post-its stuck on the wall, categorized by modules and priority and then grouped and scheduled into sprints.
User stories need to be short and sweet. They should aid in punchy communication, not tell the lengthy version of the story. Sticking to this will provide the great advantage of keeping your requirements easy to comprehend while avoiding overlap.
User stories follow a simple format:
As a/an [role], I can [feature] so that [reason]
Where:
- Role – is who you are in the business or software. This is crucially important especially when scenarios are opened and explored.
- Feature – a functionality that you need to be able to do.
- Reason – why do you need the feature?
Pretty simple, right? You are not limited to the example above. You can slightly modify it, for example:
- As a [role], I want [feature] because [reason].
Can you show me how? Sure! Let’s have some real-world examples:
- As an event manager, I can get a list of participants for the upcoming Mixolutionz National Conference, so that I can arrange adequate catering.
- As a membership coordinator, I want to send automatic emails to members so that I can alert them when their membership is coming up for renewal.
Now you might think, “Yes, this is a wonderful idea! People can just tell what they want on sticky notes and post them accordingly, but how are we supposed to know all the different acceptance criteria to achieve this?”
Of course, I’ve got you covered! On the back of the index card, write the acceptance criteria by following the template below:
Given [context]
And [some more context]
When [event]
Then [outcome]
And [another outcome]
From this, in a straightforward manner, developers and QA will be able to confirm whether the developed functionality works according to specifications. If you see yourself writing more than three acceptance criteria, you might want to rethink your user story (split it into two or more stories) or maybe the overall requirement.
Connect the Dots
Once you have gathered all the users’ stories, it’s time for the team to connect the dots! Yes, you have stories straight from the users and stakeholders, but it won’t make sense if you are not able to connect them and form an effective and consolidated set of requirements with corresponding acceptance criteria. Mixolutionz can help in every step of your journey, as well as making your requirements come alive in services that help you reach, acquire, maintain and grow your customer base.
