- 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.
Most teams don't, and if you're looking at Story Point estimation, you almost certainly would not.
Generally, backlog items are focused on the deliverable, not on the work. So, you might have a backlog item that says "A person looking for an online lesson can sort all available lessons by topic area." This backlog item would include all of the analysis, development, testing, UX design, etc in order to deliver that capability.
Some teams additionally estimate the tasks that make up those backlog items and that is often done in hours. Usually they do this for very specific learnings. If your team isn't trying to learn something specific from those estimates, I wouldn't recommend it and I certainly wouldn't try to use those to forecast anything.
Do you estimate tasks for analysts?
Typically the whole team estimates together on backlog items. This is particularly true when the team estimates using story points.
Some teams do break these backlog items down into sub-tasks and they may ask specialists (like analysts) to estimate on them. One of the main reasons they do this is avoid the specialist becoming under-loaded or overloaded.
Can you use user-stories for this purpose or you need to use tasks?
User stories are backlog items that deliver end-user value. From the examples you give of the work done by the analyst is seems more appropriate to use tasks for them.
Note that it would not be unusual to have an analysts working on sub-tasks of a user story.
Do you use spikes when estimating such tasks? What if half of your team consists of analysts?
A spike is a time-boxed bit of work that is designed to provide just enough information to allow the team to estimate on a backlog item.
For example, a team is working on a story and they aren't quite sure how much analysis it will involve. They could have one team member spend half a day investigating it. The team member would then report back their findings to the team and hopefully the team would then have sufficient understanding to estimate on it.