4

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

  • Most examples you gave to me are red flags regardless of representation on a board. How is your backlog structured? Do you have user stories? Do you break them down into tasks? What do you put onto the board normally? – nvoigt Jan 23 at 17:11
  • We have user stories that are selected to enter the sprint and we break them into different tasks, the example I give of the email is an example of something that is not within the sprint but requires a response from the development team. – ENDK Jan 23 at 17:21
  • What's in these emails that it takes hours per day reading and replying? If this work is really part of the software development process, it should probably be added to the board. It's more likely that these are actually management or support related tasks, not relevant to the current sprint or maybe even the current project, in which case the work shouldn't be added. – Rik D Jan 23 at 21:12
  • @RikD Usually they are questions that the PO or the Analyst asks to the development team, for the work that will come for new sprints, in fact the example of the spikes, is just that, work that will be done in the next iterations of the sprint but require some feedback of the development team, that's why it takes a little time to answer it, since sometimes there is a need to analyze what you have to answer – ENDK Jan 23 at 21:18
3

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.

  • The sprint backlog can only be changed after agreement from both the team and the PO. - This is not correct. In Scrum, the Sprint Backlog is owned solely by the Development Team. The only time the PO needs to become involved is if the scope of the Sprint is changing or if the Sprint Goals are in jeopardy. If the work being added/removed is in support of already planned Product Backlog Items brought into the Sprint, then the Development Team can choose how to represent that work. – Thomas Owens Jan 24 at 20:26
  • 1
    @ThomasOwens: I added some clarification that I meant changing the backlog in terms of which PBIs are planned, not how the technical division of that work is represented. – Bart van Ingen Schenau Jan 25 at 7:24
0

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.