Updating Results

FDM Group Australia

4.1
  • 1,000 - 50,000 employees

Tarik Taha

In a nutshell my role is to gather business requirements for upcoming Digital projects through workshops and meetings, and then break these requirements down into specific deliverables that allows the Scrum team to supply these changes and identify the intended business value.

In a nutshell my role is to gather business requirements for upcoming Digital projects through workshops and meetings, and then break these requirements down into specific deliverables that allows the Scrum team to supply these changes and identify the intended business value.

07:15 AM

My alarm goes off and after hitting the snooze button once or twice, it’s time to roll out of bed and start my day. I grab a quick shower and head straight into the office, which is based in International Towers in Barangaroo, Sydney. It’s a great location and one that’s easily commutable.

09:00 AM

After the requisite coffee and pastry at my desk, I’m ready to begin work. The first thing I do is plan out my day along with the rest of my week based on meetings that I need to prepare for, workshops I’m involved in, and upcoming deadlines. Once I have my day prioritised, I’ll go through my inbox and respond to any emails or follow up on any queries.

10:00 AM

Every morning the Scrum team attends the Stand-Up. This is a 20-30 minute gathering where we discuss the changes that each team member is working on. We talk through what we completed yesterday, what we will tackle today, and whether there are any issues or dependencies. It’s a good opportunity to highlight issues and call out any work that will be coming people’s way. For example, one of our developers might mention that development will be complete soon and will be passed over to a Tester.

Tarik Taha FDM Group

11:00 AM

Typically, I spend the rest of my morning preparing Stories. A Story is a detailed description of a business requirement for a Project. We use a tool called Jira to create and track Stories as they progress from gathering requirements all the way through to implementation. In each Story, I must clearly outline the deliverable and acceptance criteria, along with any relevant information including mock-ups of what a particular page should look like. Stories are used by developers and testers as a guide to outline and direct their own work.

1:00 PM

There is a gym in the building – I find that a quick workout over lunch really helps to clear and focus my mind for the rest of the day. Afterwards, I grab a quick bite to eat at my desk and resume work.

2:00 PM

I hold a meeting once a week called a ‘Grooming’ session. In this meeting, my role is to clearly explain the requirements of upcoming projects to the Scrum team, and answer any questions they may have. Once the requirements are clearly understood, we can estimate the time/effort it will take to deliver the project. This can then be communicated back to the business stakeholders, so they are aware of timelines.

3:00 PM – 5:30 PM

The afternoons are usually filled with meetings or workshops to further discuss upcoming projects. These requirement-gathering sessions involve trying to understand the existing functionality that the business leverages, and what the problem statement is based off the desired state of the application we own. Once the business value that we are trying to meet is understood, and we are aware of the gap between the current and desired state of functionality, I can break down the Project into smaller requirements (i.e. Stories) that can be delivered in a future Sprint. A Sprint is a predetermined set period whereby the developers and testers work to deliver a Story.

Tarik Taha FDM Group

09:00 PM – 11:00 PM

If we are releasing one of our changes into the live environment, we need to do it outside of business hours so as not to impact the systems during times that they are in use. Once the development team deploy the Change to the production environment, we begin post-verification testing to ensure that all features are working as expected. Once successful, we can sign off the changes. The following day, I inform all stakeholders of the successful deployment, along with the changes they can expect to see when they use our application.