Want to learn how to gather requirements the agile way?
The Mendix platform provides a seamless way to manage each project. We follow the agile methodology and as such, expect user requirements to be defined in the form of user stories. For those of you less familiar with this approach, the format is as follows:
As <user role> I want to <what you want> so that I can <business value added>.
For example, consider these user story examples for a new application for course registration:
As a teacher, I want to have a class overview with the students registered so I can better manage my class.
As a student, I want to see a list of open classes so that I can register for them.
Of course, the user stories can be much more detailed. For example, including relevant data entities (such as course number, course name and course level within the user interface), project labels (such as “Integration with SAP” or “Class Registration”) and developer assignments (such as “Daniela”).
This approach to agile requirements gathering makes it easy to understand and maintain value to the business. And while traditional requirements gathering should also focus on the business need, we’ve found that it’s easier to deviate and get frustrated in those instances. Whether you’re in charge of requirements gathering or in charge of developing those requirements – miscommunication happens.
In this post, I share my perspective on requirements gathering. I’ve tried to be unbiased, providing pros and cons associated with traditional and agile practices.
Are you successfully gathering requirements with your current systems?
Let’s take a closer look at requirements through traditional models. In the Systems Development Life Cycle (SDLC) and Waterfall development models, business users and developers meet for Joint Application Development (JAD) sessions. At the end of these sessions, stakeholders have little to show except for a large document with project requirements. But before we judge, let’s take a look at the project group.
JAD methods require a large number of participants, including:
Sponsor – controls funds and makes final decisions on the project
Facilitator – plans, conducts and follows through with the results by guiding the team through the process
Scribe – the meeting note taker
Full-time participant – person(s) involved in decision making
On-call participant – person(s) affected only in specific areas for the project
Observer – person(s) sitting in on specific sessions without participating in decision making
The JAD technique was developed by IBM in the 1980s (yeah, it’s old). I’ve seen clients who run projects using this approach; it takes anywhere from a couple of months to over two years. And like anything, there are pros and cons to consider.
With a larger group and more focus placed on documentation, you can be sure that there will be little ambiguity in the project plan. Moreover, with the right individuals identified and participating in the project, you benefit from additional brainpower and ideas. Finally, participants are encouraged to take greater ownership as part of their project roles, which can lead to more accountability.
However, these pros can very easily transform into cons. With larger teams, there is often too much banter between stakeholders. Larger groups also lead to communication barriers and disjointed knowledge share. Finally, while you may benefit from more specific documentation, that assumes that your team has envisioned the perfect solution which is improbable. More likely, the group has suggested unrealistic goals that prolong the project timeline as everyone regroups to reassess.
The traditional requirements gathering process reminds me of the following joke (illustrated below). Communication is critical to success. And ultimately, business and IT users are not always on the same wavelength. This usually ends in frustration on both ends.