The ABA project has been a great learning experience for me in both dimensions this module covered i.e. business analysis and agile methods. This was possible due to the consistent practical work next to the massive theoretical read-ups from the BABOK guide. The ABA module aimed at practically teaching the agile methods of business analysis. The benefit of this approach are very aptly said in a Chinese proverb: Tell me and I'll forget; show me and I may remember; involve me and I'll understand.

My work on the project

Due to group formation problems, I joined Team 01 with a week’s delay. At this time, the Project Pitch had been delivered, the Team Trello Board coarsely outlining the project plan was in place and the final report structure was on the GitHub Wiki. Thanks to my teammates! On-boarding was smooth.

As the project was organized in three Sprints, I have similarly structured my individual report describing my role, contributions and most importantly my learnings in each of the sprints in the following sections:

Sprint 1

The Sprint started with an ambitious goal of identifying a viable solution to our problem and developing an executable digital prototype for it. The team worked together in mapping the challenge and ideating possible solutions, and then distributed tasks in developing the prototype design, content and validating it.

In this sprint, my role was primarily of an associate understanding and eliciting the requirements and questioning the identified challenges. While on one hand I was catching up on the project background, on the other hand, I was getting comfortable with my new team and their processes. The best part of working in this team has been an indistinct division of roles among the team members. This allowed for a great learning experience in different roles throughout the project.

My major contribution in this Sprint has been in the Diverge phase. I researched and analyzed the solutions already available in market to address our identified problem. Besides this, I was involved in gathering notes during our meetings in the Diverge phase and add this information to our GitHub Wiki.

For my learning, this sprint was a practical introduction to a complete agile life cycle. I work for a traditional ‘non-agile’ company, so that was a first and quite useful experience for me. Being practically involved in the complete cycle helped me better understand the phases that I had only read about. I was also introduced to two new methods, Google Design Sprint and the Crazy 8’s. I was previously unfamiliar with Google’s variant of sprint design as well as the Crazy 8s method of quick & dirty prototyping.

Sprint 2

After a successful sprint 1, the second sprint started with a goal to make improvements to the prototype based on user feedback and to collect more feedback on the new prototype. We were focusing on the end user views in order to make our solution a perfect fit to their problems.

In this sprint, I took up the role of a researcher/business analyst. I had to process the information gathered from users and extract ideas that could be incorporated in the prototype by the sprint end. We received a lot of user feedback concerning both the design and content of our solution. In my current role, I opted for analyzing this feedback specifically concerning the content of our application. This involved some study on the psychological / emotional aspects of relationships to identify what types of additional questions can be included in the application.

Accordingly, my prime contribution in this sprint was an extended and improved question base for the prototype. The purpose was to collect more information that is useful, both about the users’ partners and their perception of the relationships they have. A good quality of input data, we believed will be significant in ensuring the appropriateness of responses provided to users for maintaining their relationships.

Based on our retrospective from sprint 1, in this sprint I worked with Trello more actively. I overcame this slim anxiety I get before having to use a new software/process/prototype/anything. I came to appreciate the effectiveness of the Trello boards in managing short-spanned project cycles, as well as its ease-of-use. The practice of documenting every detail of our project regularly in the Wiki, and how that helped the team stay on top of the project activities and details also influenced my personal way of getting things done. Looking back at where I stood at the start of this project, I would count the level of comfort I achieved in working with the two tools by this time, as my prime learning in this sprint. Of course, some psychological knowledge on relationships that I read up on might also come handy one day!

Sprint 3

After having refined our question base in sprint 2, the goal for this sprint was set to make the recommendations given to users more effective. I appreciate the opportunity we had to get our sprints reviewed by different coaches each time. Each of them viewed our work with a different perspective and we received many suggestions, sometimes conflicting, but this only broadened our vision. In this case, we moved our focus from the quality of input data towards the quality of output responses. This direction for improvement was not originally in plan, and came up during a sprint review discussion.

In this sprint, I went for a technical analyst role primarily. Now that the goal had shifted towards improving the recommendation logic, we realized that our current prototyping engine (Iconic Creator) would not suffice. I researched on options that could support our goal technically and presented to the team, from where we discussed and concluded that another engine (Interact) will suit our needs for now.

Besides working towards the new prototype and getting validation feedbacks, I also contributed by working on various Wiki sections that needed some more details (as per the feedbacks from coaches).

By the end of this sprint, I had learnt how prototyping and iterations can drive a product towards exactly what the user needs or has in mind. Of course, this requires that the activities are organized with care and collaboration is a top priority. Well planned is half done! Working with small goals in perspective, we were able to execute the project smoothly.

Summary

As retrospectives during the sprints have been my favorite activity, I will end my project report with one. Looking back at our project, and reviewing the theory we learnt alongside, the design of this ABA module leaves me in a position to compare how theory relates to practice and more importantly how practice may benefit from theory.

The project prototype (Change) was constantly influenced by the users’ feedback (Need), the coaches’ opinions (Stakeholders) and the circumstances around relationship problems (Context). We, therefore, experienced the importance of the Business Analysis Core Concept Model (BACCM) and learnt how large projects may benefit if business analysis activities are centered on these core concepts.

Each of our sprints also touched upon the different Knowledge Areas (ref: BABOK). Planning was where each sprint formally began and was constantly monitored for adherence to the plan by the team members in the roles of Scrum Masters (Business Analysis Planning and Monitoring). Elicitation and Collaboration was ensured via the sprint reviews. Requirements were defined and the prototype was designed in iterations that were driven by user feedbacks (Requirements Analysis and Life Cycle Management). Hence, a compact experience of the business analysis activities was possible via this module. With no working experience in agile, this was the most significant learning for me by being involved in a practical agile project.