How do you estimate a task/story for an analyst in SCRUM?
- Do you estimate tasks for analysts? These tasks may include, for example, work with business requirements, producing documents that help the development team, sometimes write user stories descriptions.
- Can you use user-stories for this purpose or you need to use tasks?
- Do you use spikes when estimating such tasks? What if half of your team consists of analysts?
Re-Evaluate Why You Have a Distinct, Non-Scrum Role
Do you estimate tasks for analysts?
Scrum doesn't have an "analyst" role. All members of the team are "Developers." That doesn't mean you can't have analysts on the team; it simply means they don't get special titles or unique workstreams. In Scrum, their work must not be separate from the collaborative work performed each Sprint.
On the other hand, if you have analysts feeding the Product Owner or Product Backlog from outside the Scrum Team, then you're Doing Scrum Wrong. All work required to produce a Work Increment should be performed within the team whenever possible. Furthermore, detailed work should never be fed to the team in this way; Product Backlog Items (especially user stories) should generally capture what is needed and why, not how the team should implement it.
If your business analysts are Development Team members, their time-boxed level of effort should be factored into the work planned for the current Sprint Goal. If they aren't actively working on the current Sprint Goal or a component Sprint Backlog Item, they really aren't properly integrated into the team.
The recommendation here is to leverage your Sprint Retrospective events to determine why the team is treating business analysis as an externality, rather than as part of the in-Sprint collaboration process. Whether it's a skills gap, a team composition issue, or a process problem, it's essential that the Scrum Team collectively addresses the workflow process together. Imposing a non-Scrum workflow onto the Scrum Team largely defeats the purpose of Scrum's self-organizing principles. Failure to achieve the expected benefits of an agile framework will likely follow.