What to do with tasks wich are picked up but on pause, keep them in progress or back to do or.. ??

If a task is not currently being worked on but is not finished, wouldn't that be "to do" by definition? 

Honestly though, this isn't something anyone on this forum can provide an answer to.  Scrum does not provide this level of detail as it is a framework and not process.  Procedural decisions are up to the Scrum Teams to determine.  So, what does your team say when you ask them that question? What problems are they encountering because of the current process?  Does there need to be a change in the current process at all? 

Ask your team and let us know what they say.  Not because we will use it with our teams, but out of curiosity for how one team decided to self-organize and self-manage.

Some developpers have a long list of tasks in progress and sometimes even move them to next sprint.

Even if there is no impedement. Should tasks which are not active being worked on back to "to do"? 

Isn't that something you'd figure out in the Sprint Review? The whole point of it is to consider the work that has been Done and the work which remains to be Done, and to update the Product Backlog accordingly.

I'd be asking several questions, perhaps using the Sprint Retrospective as a venue to understand what's going on. I'd be specifically interested in why new work is starting when in-progress work isn't being finished and trying to understand what is preventing work from being finished in the Sprint in which it starts.

You should be asking "why?".



Why are those items not worked on? Why did those items go into a "in progress" state when now they aren't being worked on? Why did the developers start another Work Item?



And the answers need to be looked at: how can we prevent the blocking and how can we make unblocking easier? You'll have reasons and solutions. And you may want to look into "Work in progress limits".