Should architect's work and business analyst's work be part of sprint backlog
We have a scrum team of 6 (4 devs and 1 tester and PO). We have an Architect and BA who work very closely on a daily basis with this team and help in technical roadmaps and alignment with external teams/discovery work and unblocking work for the team.
Currently all of this is also part of the sprint board and gets discussed on a daily basis as the team is also looking for updates from the architect and BA. Hence they join the standups and update the team about the progress from their side as well.
However the flipside is, many a times a lot of work which are assigned to architect and BA gets spilled over as they are waiting on alignments etc and this doesn't show very well on the board. At the end of the sprint, when we look at the board, there seems to be a lot which is not even started (most of the time spikes etc. which the architect or BA is doing).
On one side, we think it is quite beneficial for the team to have visibility of everything on the board, but on the flipside a lot of tickets spilling over.
Any suggestions on whether we are doing it right or if there is any better way to handle this situation.
In Scrum, work does not spill over. An increment is either Done or not.
Anyone whose effort is required to ensure that at least one Done increment, of immediately usable quality, is produced each Sprint is a Developer. Their work is not assigned -- it is pulled -- and they have a shared view of all the work they must collaborate on that Sprint, and of how much remains.
My opinion is that if the work they are doing is directly related to the Sprint Goal, then it should be on the board. If not, then it doesn't need to be there as it can distract people from the Sprint Goal.
If the work that they are doing that supports the Sprint Goal can not be completed during Sprints, I would expect this to be a retrospective topic until such time that enough adaptions have been made that it becomes possible.
Remember that the Daily Scrum is not a status meeting. It is a 15 minute time box where the Developers discuss new findings and plan out their work for the day that will allow them to reach the Sprint Goal.