Embrace Agile Requirements Gathering And Best Practices
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.
Are you ready for greater agility as you gather requirements?
With Mendix, the goal is to be flexible and agile. At the start of an application project, the users and their roles are identified. There are fewer individuals involved in the project, as you see below, and they each bring unique domain knowledge to the project.
- Sponsor – the ultimate decision maker
- Subject matter experts – the business users
- Business engineers/developers and QA team – the development team, depends on project complexity and scope
Once the team has been identified and roles have been reviewed, the group meets to write down the user stories and divide them into weekly or bi-weekly development sprints. With each sprint, the team ends with a working prototype to help all stakeholders visualize progress and ensure that all efforts continue to solve the business need. I’ve worked on projects where we’ve shown a demo to end users within the first week.
Remember the following diagram from my previous post?
After a prototype or demo is released, the business users can immediately see if the application behaves as expected. There will likely be iterations required, as it can be difficult to compile every requirement from the outset (because, as the first illustration shows – people don’t always know what they need until they see what they get).
Mendix is designed and built for change. You can build applications rapidly, and easily add new or edit existing user stories based on feedback from earlier prototypes. Moreover, your backlog becomes flexible, adjusting based on new priorities from the decision makers.
But remember, an application is almost never complete. Business rules can change and so can the value proposition. IT needs to keep up. An agile approach to requirements gathering allows the project team to adapt over time.
How does your organization gather requirements? What are the pros and cons of your method? Don’t forget to comment below.