Struggling in Scrum Team

At this point I really lost all hope

I'm not surprised, since at least 8 months had elapsed. In Scrum, the maximum leap-of-faith that should be taken before such issues are flushed out and dealt with is one month. An integrated Increment of usable quality is produced in that timeframe and thereby used to manage risk.

My advice is to reconsider your assumption that the bank is "using agile". They seem to be doing something else and are getting different outcomes.

What can be done to resolve the various dependencies and assumptions earlier, so the leap-of-faith is reduced to a Sprint?

Thanks Ian. Definitely Agile is used and it has been preached continuously. What I am thinking is is not this something the Technical Devs and POs should already know? Why is it that Mapping Exercise only occured to them after 8 months? Is my assumption of the POs SMs and DEVs not knowing their job is correct?

I agree with @Ian.  The explanation you provided sounds very lumbering.  Being agile means you can quickly adapt to change.  An 8 month period to determine that they don't have the correct information is pretty slow. You never mentioned what role you are fulfilling but since you specifically mentioned PO as being someone else, I am even more confused. 

If I were in your position, I would stop trying to get the information that they want and start working to connect the people that need to be communicating.  Instead of gathering the information, work to connect the two groups that have/need the information and let them work out the details. 

In addition to all the great comments, we have a saying in the Agile community: FAIL FAST.

I am fulfilling a role of a Junior BA. I have no experience or whatsoever in a technical environment yet I am being given all the technical items which is really stressing me. 

And Definitely Agile is used in the Bank and it has been preached continuously. What I am thinking is is not this something the Technical Devs and POs should already know? Why is it that Mapping Exercise only occured to them after 8 months? Is my assumption of the POs SMs and DEVs not knowing their job is correct?

Why is it that Mapping Exercise only occured to them after 8 months? Is my assumption of the POs SMs and DEVs not knowing their job is correct?

I am going to assume that your assumption is not correct only because it would be difficult for them to do their job if it was.  I believe that they are conditioned to expect that the Business Analyst would do this work far ahead of their need.  And since you did not do it, it is only coming to light at this time. If the work is just beginning, then they are probably just starting to actually look at the requirements.  They have had high level information that they have used to provide high level estimates.  Now the work is bubbling up to the top of the order and they are starting to take a closer look at the needs.  

Take this as a learning exercise for yourself.  Learn from this so that you will be able to be better prepared next time.  Ask the Developers for guidance and explain that this is a new experience for you.  Let them help teach you how to do your job in a way that benefits them the most.

I guess my first question to Deepak is what role are you fulfilling in the project.  He has indicated in the Nov.1 comment that he is a Junior Business Analyst.  I would think that the product owner should be passing the Developer questions on to Deepak's manager to get the information, ie: field details, mapped and put together. 

Sounds like the Scrum Master or some project manager needs to put together a roles and reponsabilities chart.

I’m sorry to hear about your frustrating experience with the system migration project. It sounds like there was a lack of communication and clarity among the different teams involved. System migration is a complex and challenging process that requires careful planning and coordination. Writing user stories for system migration can help you define the scope, requirements, and acceptance criteria for each task. User stories are short and simple descriptions of a feature or functionality from the perspective of the end user or customer. They usually follow a template like this: As a <type of user>, I want <some goal> so that <some reason>.

To write user stories for system migration, you need to identify the following:

• Who are the users or customers of the system? They could be internal or external stakeholders, such as business partners, banks, regulators, etc.
• What are their goals or needs? They could be related to data quality, security, performance, compliance, etc.
• Why do they need those goals or needs? They could be related to business value, customer satisfaction, risk mitigation, etc.

For example, a user story for system migration could be:

• As a bank, I want to receive a file showing all transactions processed by the new system so that I can verify the accuracy and completeness of the data.
• As a regulator, I want to access the new system’s audit logs so that I can monitor and enforce compliance rules.
• As a customer, I want to use the new system’s online portal so that I can view and manage my account details.

You can use the web search results I found for you to learn more about how to write user stories for system migration.

In a nutshell, my understand is that as a Scrum master you are trying to manage the team, and even take over other people expertise, where you are actually expert.

Please allow me to just give simple advice.

• Failure is an asset in Scrum. That's why it is the best risk management tool ever. Once you,aas a team, identify a problem, team should find way to solve or wrap around the problem
• Don't try to solve problems. Make sure that OTHER TEAM MEMBERS solve them. Your job is to make sure they do it. Help when IF YOU CAN.
• It's ok not to have a clue about someone's field of expertise or IT in general. In a feature team everyone is an expert on his own, and you must be an expert in Scrum, not testing or Python programming(for example). Make sure that there is an environment where everyone is working on solving problems together
• . It's 2023. Don't limit the outcomes to transparency, inspection and adaptation alone. Use collective database of human intelligence (this includes machine learning, which is a database, not an "intelligence" of any kind)  to gain previously unknown information fast and adapt to it.

In a nutshell remember that it is not your job to command and control team into success. It is your job that the team will properly identify the value of their work, visualise the path to success, map the value stream, make it flow, make shure that people pull the ideas, and end users pull your product instead of pushing it to them, and think how you can continuously improve the whole thing.

It's called "Lean thinking".. Together with empiricism(only learn from a past, don't try to predict the future) lean thinking is a cornerstone of Scrum and Agile. Like a Holy ghost of scrum guide.