In part 2 of our ‘Living Our Values’ mini-series, Deniz Berrak explores what the core value, “Embrace Change”, means to her
As a company, lives and works by 6 core values. These values govern how we do business, how we plan for the future, and how we understand and support our team. In part 2 of our ‘Living Our Values’ mini-series, Deniz Berrak explores what the core value, “Embrace Change”, means to her — at and beyond.
As a company,
When I first started as a Business Systems Analyst, I learned and worked within the Waterfall approach; I sat through months-long conference calls with the same people going through the same problems, I gathered requirements like a pro and documented my heart out. I tested, re-tested, and tested some more. Then came deployment and all of us sat together holding hands, praying to whatever we believed in and hoped the system didn’t crash and that millions of users weren’t affected. In hindsight, this may not have been the most expedient approach but, little did we know, there was an easier way.
As Business Analysts, you strive to understand business goals, requirements and exception scenarios in addition to identifying assumptions,
In Agile we still go through the process of identifying goals and gathering requirements but we’re less concerned with making things perfect and more focused on diving in and learning from the process.
What I mean by that is that we want to get our requirements in front of the stakeholders as quickly as possible so that we don’t waste time building something that isn’t what they wanted (core value: fail fast!). For instance, if you have a client meeting instead of trying to focus on the end-to-end solution, you make a conscious decision to focus on one specific piece of functionality, like a widget on a
Once you’ve had just one meeting, in a typical waterfall project, you wouldn’t be ready yet to present your Software Requirements Specification (SRS), but that’s the beauty of Agile because you can, in fact, start formulating requirements right away. In this case, we just name them a bit differently and so Business Requirements become User Stories. Early on, I figured out a set of criteria for formulating effective User Stories:
As a (type of actor), I want to (
Example: As a customer, I want to be able to view all available products, so that I can select and purchase the one most suited towards my needs.
These User Stories can be used as a starting point to discuss available options with your development team/tech leads and use them to put together a draft of the System Requirements – or in Agile terms the Acceptance Criteria to give the story more detail.
Acceptance Criteria will typically be a description of what this piece of functionality needs to achieve in order for it to satisfy the business needs/requirements.
Example: user should have the ability to filter products by: price, colour and style
Thanks to this foundational work, by the next meeting with your client, you’ll have your User Stories (Business Reqs) and draft Acceptance Criteria (System Reqs) for one specific piece of functionality. Once you review it with your client, you can make the necessary updates and pass it on to your dev team who now has an actionable piece of work they can get started on. You then go back to your client — and while your dev team is working — you go through the same exercise again until you’ve documented all of them. In the process what you’ve done is created a Backlog (repository of User Stories with detailed Acceptance Criteria) that your dev team will continue to work from.
What this allows you to do is facilitate continuous development integration which allows you to fix any issues before you get too far down the road. Your role as a BA is still the same, you just adjust your process and change the way you present your work.
As I mentioned in a previous post, I view my role at
We’re always looking for great team members. If you’d like to grow with us, please reach out and see what career opportunities are available.