Moving tasks back to the 'todo' column on scrum board

If an item is moved back then this implies that the board was not telling the truth at some point. The team ought to have process rules for ensuring that work has been performed satisfactorily before being moved from one station (column) to another.

It's possible that new work may be discovered during a Sprint, in which case that may reasonably be captured as a new work item. 

So, a task that is in 'doing' should not be moved back? That's what I think but I can't find any articles on this matter. 

What should a team do when they realise that having started to work on one task, it makes sense to cease (or even discard) that work, and do something else first, in order to give themselves the best chance of reaching the Sprint Goal?

In such a situation, although moving the task back to "to do" may be an indicator of a systemic issue (which perhapz warrants further investigation), it doesn't feel inherently wrong to me.

What do the rest of the Development Team feel about this change to the Scrum board?

Isn't it the purpose to reflect the current state of progress in the sprint?

If a developer tries to solve a task, therefore moves it to in progress, figures out it was way harder then expected and decides to drop it without actual progress on the task itself, keeping it 'in progress' would be odd as nobody is currently working on it. Somebody still needs to do this task.

The development team owns the Sprint backlog, which contains the most up to date plan to accomplish the sprint goal.  If in fact the work for that task has not started, then don't you think it was the right thing to do?  I would assume it was moved to the To Do column by mistake. Would you rather have the work show the incorrect state?  There are times when the team learns that a task they created is no longer needed, and they can remove it as well. 

If the sprint backlog is an up to date source of truth, and the team understand where they stand with the sprint goal, then I would not focus on this.

Al the best!

Chris

@simonmayer: the scrummaster of the team is okay with it.

I understand the need and logic of moving tasks back or even delete a task but in this case, the developer had in fact almost finished the task (succesfully). He moved it back to 'todo' because he wanted to work on another task that day and didn't want to many tasks in the 'doing' column. I found that odd. For me as a coach the physical scrumboard should reflect the state of the sprint and not the state of the day.

He moved it back to 'todo' because he wanted to work on another task that day and didn't want to many tasks in the 'doing' column.

That's an anti-pattern right there, does this reflect current and correct status of the task ? If the answer is 'no' then you know its will easily be misleading.

I think it's important to understand the reason it made sense to the developer to stop working on one task before moving on to another.

Perhaps this shows the tasks weren't scoped correctly, or maybe the particular developer faces some difficulty which prevents him focusing on one task from start to finish.

It could also be that new insights meant it made sense to switch work to something else. In which case, perhaps the developer intended to be agile. However, there might be a better way for him to have dealt with it.

It's important that changes to the board do not compromise transparency.

Based on whatever reason the developer had for moving the task backwards, do the rest of the team agree this was the right thing to do? Do they feel it helps or hinders transparency?

didn't want to many tasks in the 'doing' column

Why doesn't the developer want too many tasks in the 'doing' column? What is wrong with having many tasks in the 'doing' column? Are there any incentives which foster this behavior? 

Maybe there might be questions what the 'doing' column on the board means. Is it 'someone is currently working on this task' or 'work has been started on this task'? 

It worked as it should. In general, the flow should be from left to right, as you described. If it is not, then it should be noticed and discussed. The role of the board is to make it visible. The role of the scrum muster is to notice those things and minimize such situations.

Lean practice is to minimize work in progress, but also minimize task switching. I would recommend investigating what was the reason. Did he started another task? Did he returned to previously done task? Did something blocked him from working on the tasks that was moved back? Did something blocked the other task and he started working on yet another? Maybe the task is not ready for implementation and therefore should not be in Sprint backlog?

This is the moment that scrum master should notice and react. Not just to keep board up to real life (which is good)  but also notice such symptoms and correct them.

He moved it back to 'todo' because he wanted to work on another task that day and didn't want to many tasks in the 'doing' column.

Let's assume that, as a professional, his decision to switch tasks was the right one to make at that time. This presupposes of course that his decision was not arbitrary, and that it was agreed with the rest of the team.

In that case, the board simply needs to reflect the fact that no-one is currently working on that task. Technically it is blocked (due to unavailability of a developer), and a red "BLOCKED" sticky note may therefore be placed over it. However, since this is more of an internal impediment than an external one, another less precipitous convention may reasonably be used. I coach teams with physical boards to simply turn a card upside-down to show that the item is locally impeded. This is enough for the team to have transparency over their situation, and does not message to those outside the team that team tolerances have been exceeded (such as would be the case with an external blockage) and escalation is in effect.