Business analysis activities still take place in Scrum. But there is a significant change in how requirements are identified and described: It is now a team effort, and no longer the job of a specialist. The development team should reserve 5-10% of the time available in a sprint to work on the product backlog together with the product owner, for instance, in a product backlog grooming workshop.

As a consequence, the job of a business analyst in Scrum changes: The individual either plays the product owner role or becomes a team member. In both cases, the BA takes on new responsibilities. As a team member, the individual is likely to help with testing and documentation or with architecture and development work – depending on his or her skills.

After reading your post, as well as a few articles on the web (see references below), I came to the conlcusion that:
1. During a Sprint, BAs work on analyzing requirements for the Sprint(s) to follow. They do however actively support the Scrum team in case of (business related) questions/misunderstandings, etc. in the current Sprint.
2. Thus, BAs are not part of the core Scrum team, but rather part of the project team as a whole. This is because they are not working on the same context/goal within a Sprint. They are doing analysis for future Sprint(s), while the Scrum team works on items that have already been analyzed earlier (if not fully, at least at a great extent).
3. BAs work in analyzing requirements for future Sprint(s) is facilitated by the so called “backlog grooming cycles” that take place in parallel to the “Sprint cycles”.

Can you please share with me your thoughts on the above points?

Thank you in advance,
Ioannis

References:

[1] Is the Business Analyst a Product Owner or Tester on Agile Projects?
http://www.batimes.com/elizabeth-larson/is-the-business-analyst-a-product-owner-or-tester-on-agile-projects.html

Extract:
So how can BA do all the things BAs do so well without preventing the team from delivering an increment in short time frames, such as 2-4 weeks?
By ensuring requirements are defined completely and correctly before each sprint begins.
The BA can work with the product owner and other business and technical SMEs (Subject Matter Experts) as the delivery team completes each sprint.
However, the BA is working on requirements for the upcoming sprint, rather than the current sprint.

[2] Requirement analysis and Design flow in Scrum
http://www.scrumalliance.org/articles/149

Extract:
In conclusion, you can see the value of requirement understanding and design in the following Scrum activities (major ones in bold).
Requirement: backlog grooming (several rounds) -> Sprint Planning part 1 -> Sprint Planning part 2 -> Sprint -> done -> sprint review
Design: backlog grooming -> spike item (when necessary) -> Sprint Planning part 2 -> Sprint -> done

[3] Business Analysis in Scrum
(see “The Agile Extension to the BABOK Guide”, IIBA, November 2011; paragraph 2.1.4 on pages 17-18)

Extract:
Scrum does not address business analysis activities in detail and many of these activities occur as implicit steps in the scrum framework.
The building and maintenance of the product backlog is a significant business analysis activity that falls explicitly outside the scope of the scrum framework (although other methodologies have addressed this). The backlog is built through a combination of enterprise analysis work (identifying gaps and new capabilities required to accomplish organizational goals, and defining their value to the organization) and solution assessment and validation (identifying ways in which the existing solution can be enhanced to better deliver business value).
Within a sprint, business analysis activities focus on defining the requirements for the backlog items being worked on and the acceptance criteria for those items. This method is frequently referred to as just‐in‐time requirements gathering; developing only what is required for the current sprint and only done to the level of detail required to enable the team to build the product and acceptance criteria. In traditional methods, requirements documentation is frequently used as the documentation for the solution. In Scrum, as in most other agile methods, documentation is created after the product is built to capture the team’s knowledge, not define an expected or desired outcome. Most frequently the backlog documentation created during each sprint serves as sufficient documentation for the project.

technical writer are important whether it costs money take care of or not. Supporting information is vital and so your post Business Analysts in Scrum ” All Things Product Owner – Roman … makes interesting reading. I hope many see it and take notice…