Stories STATUS

These are questions that the team will have to decide. Even as the team decides, the answer could be situational.

What happens to the status of the story?

Your stories are most likely what Scrum calls Product Backlog Items. The Scrum Guide doesn't say much about how to manage the status of work, but it does say that the Sprint Backlog is a "real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal". If you are using workflow states, such as "in progress" or "in development", as statuses, then the work no longer being in the Sprint Backlog doesn't change the fact that work started and is currently in progress.

However, I can see arguments otherwise. Perhaps the team will decide to throw away the work. If they throw away the partially done work, then it would no longer be in progress and would have to be fully restarted, so changing the status of the work could make sense. Your statuses could also be reflective of where the work is, such as "in Product Backlog", "selected for Sprint", or "Done", in which case it would also make sense to update the status if it was no longer in the Sprint Backlog.

Does cycle time include these stories if we leave them in progress (original status from the sprint)?

This is also highly situational. If you're going to pick up the work soon, I would lean toward having the cycle time to continue running. However, if the partially done work is being thrown away, there could be an argument for resetting the cycle time to reflect how long it takes to deliver the work. Consistency is key, though - make the same decision for all work so that cycle time is meaningful. If you do change, then metrics that consider cycle time may be skewed while old data filters out of consideration.

What about blocked stories taken out of the sprint (during or at the end of sprint) to the backlog? Do they stay in blocked status?

I tend to discourage teams from treating blocked as a status. I prefer statuses to reflect steps in a workflow rather than metadata. Blocked work can be annotated in other ways and becomes visible by visualizing work item aging.

If I have tickets are go back to the backlog fro the sprint, and this is justified

Think of it this way: if a piece of work isn't Done and is still valuable, it never left that backlog in the first place.

The right thing to do is to make sure that a backlog tells the truth, at all times, about the work that is currently understood to remain until a goal is met.

The Scrum Guide doesn’t specify what to do, so it's up to the team or organisation's process. A common practice is to reset the item to its original backlog state (e.g. "To Do"), re-estimate and re-prioritise it. Cycle time also resets. While some teams carry items over between sprints, best practice is to return unfinished work to the backlog and treat it as new in the next sprint.