1

We use the usual "to do" "doing" "done" and "blocked" columns for our internal organization.

I'd like to know how I should handle tickets that are in "to do" but are not immediately actionable because the ticket will be done during a scheduled meeting. Does it go in "blocked" because it's not immediately actionable or does it stay in "to do" because it's not really blocked (there is no problem to solve about this ticket) ?

2
  • 1
    Do you have a Definition of Ready? One of the criteria could be that it's not blocked!
    – Liath
    Mar 23, 2018 at 15:54
  • 1
    You may not have enough queues for your process. The designation of blocked or waiting doesn't matter as much as your WIP limits per column and/or swim lane.
    – Todd A. Jacobs
    Mar 27, 2018 at 2:16

4 Answers 4

3

I believe it's hard to get a canonical answer for this question. In this case, the best answer would be something like whatever works better for you and your team.

How to assess this? Well, maybe doing some experiments, the good ol' trial and error. Before going into them, some assumptions could be made that might be helpful on the empirical testing:

Considering blockers

  • Pros: Segregate items that cannot be started now, leaving a 'clean' to-do list

  • Cons: Doing so could be a Scrum Smell, as an item that's not ready to be implemented should not be considered to the current iteration (and I second Liaths comment - you should have a good DofR)

Considering ToDo

  • Pros: You'll ensure Scrum Master will be dealing with actual blockers rather than raising potential false alarms - the Scrum Master might have enough on his plate dealing with actual blockers to be concerned about a (assumed) controlled dependency to make it to the sprint goals

  • Cons: Depending on the nature of the project and the expectations the Product Owner has, if it may become a blocker then the PO might come with the complain that 'he should have been warned before'

There are several other factors to consider, but all in all, you need to find what works better for you and your team.

Bottomline: My gut feeling says that your blocker ratio is very likely to be inversely proportional to the maturity level of the team, so if you're running a senior team with seasoned PO, having these items on 'ToDo' shouldn't be a problem. Likewise, if you live on a challenging environment with scary POs, having items highlighted as 'blockers' could improve transparency in case plans go wrong.

2

My Team did two separate approaches; one for Scrum (as you have tagged your question), one not.

For Scrum, all we had to do was never accept an issue into the Sprint unless we were sure it was immediately actionable. Thus, anything in the Sprint Backlog 'TODO' column was immediately actionable. Anything not immediately actionable was kept in the Product Backlog (which did not have columns).

For non-Scrum, we simply added a 'Ready for Development' column between 'TODO' and 'Development Started'.

0

Does it go in "blocked" because it's not immediately actionable or does it stay in "to do" because it's not really blocked (there is no problem to solve about this ticket) ?

It sounds like you're describing a difference between "unavailable for immediate work" and "impediment exists". You might want to use something like "on hold" for the former and "blocked" (or "impediment") for the latter. Or, for the case where the task is on hold because you've already planned when it will be worked, just call that "Doing".

I agree this is one of those "whatever works best for your team" situations, which means it depends on how your team uses those columns.

0

It seems obvious that there has been some unexpected change or discovery.

  • You can block the story (awaiting for me) if you think it can be done before the end of the sprint
  • You can return it to to do if you have done nothing with the story but defining it (no code), again, if you think it would be done in the sprint
  • You can split the story, if possible, and advance the work done while the rest goes to to do or out of the sprint
  • You can remove the story from the sprint as the scenario has changed and you cannot maintain the compromise. It is hard sometimes but it reflects the reality of the sprint, the sooner the better
  • The PO can cancel the sprint and start again. Maybe the story was so important than it makes no sense to continue with that sprint without it and is better to change the sprint goal

It's all about team communication as you have a lot of options to choose from.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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