Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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) ?
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:
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)
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.
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'.
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.
It seems obvious that there has been some unexpected change or discovery.
It's all about team communication as you have a lot of options to choose from.
