Hello friends,

Welcome back to my #SwottingAsABusinessAnalyst series. Read my previous post here.

If you're new here, explore the initial post of my journey 'Swotting' as a budding Business Analyst.

As Week 11 wraps up, it's been a week of hands-on involvement and stepping up into some of Business Analyst works.

Here's a rundown of the key takeaways:

#1 Independent Documentation Completion:

This week, I focused on completing documentation independently. It was a valuable exercise in consolidating my understanding and articulating concepts effectively.

Documentation and Elicitation is considered as one of the important skills as a BA. Following are the overview of the documentation’s purposes :

Document Purpose : To serve as a current reflection of product feature status of all users and how users’ feature relate to one another

Tool used : Confluence by Atlassian

Activities involved :

• Understanding the nature of the product e.g the product the team is developing is a job employment platform for both candidate (user 1) and employer (user 2).

• What is the nature of the current product feature e.g what is the struture of the product feature as is now; BA is expected to analyse the product feature and summarise them into the document. For a web and mobile development, there will be following features that will be available and/ or developed by the team. Refer below (The items mentioned below can be accessed on the platform where our products are showcased. See attached images for examples of the products our team is developing)

  • Identifying ‘badge’

  • Identifying ‘content’

  • What is the trigger to the user experience

  • What is the time lapse (how much time required before the ‘badge’ is being updated

  • The availability of the features on across all platforms

• What is the nature of the future product feature e.g future designed which also can be a prototype will be created on a tool (called Figma)

• Analysing the current vs future design, noticing the difference if new feature is to be added/ removed/ remain as it is.

My personal takeaways from this exercise in the last two weeks :

• Elicitation skill : Understanding the requirement and purpose of the document e.g what is this document used for, why are we doing this, where do we get confirmation on the content added into the documents etc.

• Documentation skill : Making sure the information is succint and not convulated

• Analysis skill : Capturing the consistency of the design

• Communication skill : Ask to clarify and challenge thoughts (not in a bad way, but constructively that will bring value to design)

• Stakeholder engagament and management : Knowing who is involved in this work to help with the better completion of the documentation.

Related blogpost : Elicitation

Note: Documentation can serve various contexts and purposes. The exercise I undertook was just one example, marking my initial foray into documentation.

#2 Active Participation in Meetings:

Being part of important meetings provided invaluable context and insights into ongoing projects. It was an opportunity to dive deeper into the work and understand its intricacies.

Tips for active participation are to understand the agenda before hand and to ask question for clarity (context, takeaways and if there are any action plans)

#3 Sprint Pre-Planning:

Participating in sprint pre-planning sessions helped me grasp the project's upcoming goals and objectives. It also allowed me to contribute ideas and suggestions for the upcoming sprint.

#4 Engagement in Design Meet Up:

Design Meet Up (internally, team name this meet up as “Design Office Hour”), which was meant to engage team’s agreement on the future design before the actual development is kicked off. This session can be done in 30 to 60 mins (depending on the complexity of the design work ), it can provide exposure to BA on various design aspects, principles and enriched with product development process.

This is also considered as part of Stakeholder Engagement skill.

#5 Bug Testing

Bug Testing, also known as Bug Bash (that’s what we called it within the team), is a collaborative effort among team members to ensure that new features behave as expected before release. As a BA, you'll organize these sessions to catch any glitches and ensure the smooth functionality of developed features. There are few steps to be able to contribute to this successfully, which I am going to document the learning in a separate discussion after abit of proper research!

#6 Planning for First Retro:

Looking ahead, I have done my first retro! The planning process involves organizing the agenda, setting the tone, and ensuring an inclusive and productive session for the team. We used Retrium and it well pretty well (Much easier than MIRO in my opinion)

Related blogpost : How to run retrospective using Retrium in 11 steps

Overall, Week 11 was about taking initiative, stepping out of my comfort zone, and embracing new responsibilities. It's been a rewarding experience, and I look forward to applying these learnings in the weeks to come.

Found my content helpful? Consider to tip me a coffee via Ko-fi!

You can also explore my other blog post on Agile Delivery, Project Solutions, Agile Mindset and Career Bits on WorkWizard. Leave me a comment, would love to hear if we are on the same wavelength!

Read this article on medium : https://medium.com/@wawahalim