Tasks for Functional Team
My question is how to handle the tasks for functional team. If a member of the team will make a documentation on Confluence page or make an analysis about a specific topic, should we create tasks for these, assign them to the specific person of the functional team, define the task (task in Jira not the user story) and include them in the sprint backlog? Is there a best practice defined about this topic?
Are these tasks tied to a Product Backlog Item(PBI) that has been completed in a previous Sprint? If so, why wasn't the work done at that time? This scenario seems to be creating technical debt as a conscious decision. I usually coach that in these situations a PBI is created that defines who needs this, why it provides benefit, what that benefit is and how you know you know you have satisfied the need. Sound familiar? Yeah it is the basics of an User Story. However, whatever Jira type you want to use doesn't really matter as long as the Scrum Team realizes that it should be ordered equally with all other PBIs.
Do the tasks add value for any stakeholder? If not, why do the work? If so, I usually coach that in these situations a PBI is created that defines who needs this, why it provides benefit, what that benefit is and how you know you know you have satisfied the need. Sound familiar? Yeah it is the basics of an User Story. However, whatever Jira type you want to use doesn't really matter as long as the Scrum Team realizes that it should be ordered equally with all other PBIs.
Is there a best practice defined about this topic?
The only "best practice" is the way the team feels is best for them to handle these situations. In my opinion, this statement from the Scrum Guide section describing the Product Backlog says all that I need.
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
In my head I usually replace the "in the product" with "for the product". Does any of this work fall into the category of something known to be needed for the product? I see that as a way to cover documenting product behavior in case another team needs to know more or upgrading components to currently supported versions.
...or make an analysis about a specific topic."
Again my opinion is that this is basically the definition of a Spike and yes there should be a PBI for it. The only difference between Spikes and other PBI types is that Spikes are time-boxed and not estimated.
In general I agree.
Just a small note: a "spike", even though time-boxed, if included in a sprint, needs to be also estimated. It could be estimated employing time-box length.