When is it reasonable to register an activity on the SCRUM board and when it is not necessary?

Question

In my work we use the scrum board for the registration of activities, however there is always a dilemma of what to register there, some colleagues want to register on the scrum board the email answer (even to create a new user story), arguing that both the reading and the answer cost them approximately one hour of work, others think that it is not necessary to do this, another example of the problem occurs with the analysis of the requirements (spikes) that remain several weeks on the scrum board without moving, this because it depends a lot on the availability of the users, some consider that it is necessary to have the record of this activity on the sprint board and others consider that it is not necessary because it is an activity that takes several sprints (weeks or months) to finish.

Searching the web and forums, I find a lot of discrepancy, some justify their response using a measure of time (if the activity costs more than an hour, register it) and others justify it using a measure of complexity (if the activity costs work in a matter of analysis or development register it, no matter how much time it costs you), but the answer still does not remain clear.

For what it leads me to the question, when is it considered reasonable to record an activity on the board and why?

We have user stories that are selected to enter the sprint and we break them into different tasks, the question is focused on the task register either new within the same stories or for tasks that do not belong to a story within the sprint (like answering the email ).

We have the separate board in:
BackLog
Analysis
       Ready for analysis
       Analysis in Progress
       Completed analysis
Development
      Ready for development
      Work in progress
      Code revision
      Completed development
QA
      Ready for internal Release
      Ready for Testing
      Testing in progress
      Completed testing
Business acceptance
Done

Answer 1

There is no hard rule when tickets should be added to the Scrum board and when not.

There are two "golden rules" that can get into conflict with each other and need to be balanced:

1. There should be no invisible work. All work done for the project should be visible on the board.
2. The sprint backlog can only be changed (in terms of adding/removing PBIs) after agreement from both the team and the PO.

Assuming we are talking about work/questions that pop-up without notice (so they couldn't be planned for) and that can't wait till the next planning session, my practical approach is:

• If the work involves making changes to the product or related artifacts (like tests, documentation, etc.), then there must be a ticket for it on the board.
• Otherwise, if doing the work takes less time than the time it takes to create a ticket and get it on the board (including the discussions), then just do the work.
• Otherwise, I recommend creating a ticket for it.

If the small interruptions are frequent, then I would recommend recording the cumulative amount of work somewhere and report that during the sprint review as "unplanned work". You can then discuss if the capacity of the team should be adjusted to create some 'spare' time for this kind of work.

Answer 2

The key thing with Scrum is to only work on things which are in the Sprint.

If you are doing something and there isnt a Task for it, then its an impediment. Don't do it!

Now the tricky bit is when you 'have' to do stuff thats either completely unrelated or ill defined.

So for the first example answering unrelated emails, fixing a bug in some other product, going to a meeting etc.

Put these in the sprint so that you can later see why the sprint goal was missed. "Why didnt you complete task x?!" "because I did these other things"

The second case of 'ill defined task' sounds like your investigations, which rely on other teams who are not part of the sprint. You need to get that input before the task is put in the backlog. Otherwise you can't write a definition of done, or estimate the task.

Answer 3

If you seriously feel and ad hoc task would frustrate your regular planned work, you either put it on the board as an expedite task (or whatever you want to call it) or you create a backlog issue for it that can be discussed (and possibly planned) later. It would have to be real urgent to do it straight away.