Story is uncompleted due to deployment tasks

What you describe might be the right option (particularly in the short term).

But this looks like a source of waste. There's a cadence to releasing, which will cause a longer lead time, in terms of getting things to production. This can be waste in the sense that early opportunities to realize value or gain feedback are lost.

Furthermore, if this deployment process takes a significant amount of time, that's waste that could perhaps be eliminated through automation.

Are the Scrum Team doing anything to eliminate, or at least provide transparency over this waste?

The question is -  on Sprint Backlog , does Team should take technical stories related to previous sprint like "deployment of story A, deployment of story B.." on the Sprint Planning?

The work is not Done. Something has to happen (deployment) between the end of the Sprint on Thursday and Tuesday, before it can be released. Now you're trying to figure out how to repay that technical debt.

I'd therefore suggest asking a different question: how can we put transparency over technical debt and challenge it -- including any organizational constraints -- so by the end of a Sprint all work is Done including deployment, and increments are immediately releasable?

How long does your deployment take? How much effort is required from people to initiate, monitor, and confirm successful deployment?

There are a few different ways to approach this.

I don't have any major concerns with your Definition of Done, especially since there are constraints outside the team on sticking to a common deployment schedule. However, I do see some opportunities for improvement.

One possibility could be better to align your common deployment day with the Sprint cadence. Having the deployment on a Tuesday can be a little rough since I'm not particularly eager to hold events on Mondays due to the number of holidays and vacations that disrupt the cadence. Depending on the exact timing, you could finish the work in pre-production by Tuesday, conduct the Sprint Review on Tuesday, deploy on Tuesday, then hold the Sprint Retrospective on Tuesday or Wednesday morning and Sprint Planning on Wednesday. If the deployment is a more hands-on activity, you could hold Sprint Review on Monday, deploy on Tuesday, and the Sprint Retrospective and Sprint Planning on Tuesday or Wednesday.

You could also move your common deployment day. Perhaps deploy on Thursday, at the same time as Sprint Review. It's not clear why the Sprint Review seems to be a gate to deployment, especially if the work is already Done. If you have multiple teams and products, forcing changing this could be a problem for other teams.

If you maintain the current structure, though, I'm not sure that you need anything in the Sprint Backlog. It could help with visibility if it's not a whole-team effort, but the effort required to deploy should come out when you measure the team's capacity. If your deployments are radically different in level of effort, I'd spend some time understanding why and streamlining the deployment process. This will have the advantage of making the deployment effort more predictable and reducing the impact on the team's capacity to do new work each Sprint.

The work is not Done. Something has to happen (deployment)

Ian, but Scrum says your increment should be potentially releasable. my increment has tested on pre production. And PO show it stakeholders  on review meeting. If their comments are positive, PO decides to  shift the story into production. So the deployment task occurs. Not? Am I mistaken

If your increment was potentially releasable, no work would remain to be Done in order for it to be released. The act of release would be trivial, and there would be no technical debt -- such as deployment -- to be mitigated in future Sprints.

PO show it stakeholders  on review meeting. If their comments are positive, PO decides to  shift the story into production.

The Scrum Guide says: "The Sprint Review should never be considered a gate to releasing value."

The Scrum Guide says: "The Sprint Review should never be considered a gate to releasing value."

What does it mean? Could you explain in more depth please, Ian? 

What does it mean? Could you explain in more depth please, Ian? 

You should not treat Sprint Review as a gate that you must pass to decide to release value or not, as soon as the value is created and ready to be released and it makes sense, you should not wait for a special "approvement event" to realize value. IMHO It addresses i.e the concept of CI/CD where you most likely have a constant flow of small releases throughout your effort. 

However, I would not agree with such a hard Ians' statement assessing your situation as not Done. There may be many reasons why your context looks like that and there always will be some effort to actually release something when such a decision is made, sometimes more work involving more people, sometimes as less as a push of a "release" button. Nevertheless, if you defined pre-production state as Done and it is the best what you can do in your context, so be it - it simply creates some risks with that last mile to go to production that you must be aware of. It may be worth challenge such DoD thought, can you set the bar higher?

It sounds to me like you are faced with a corporate decision that you can't change.  Since the company has decided that deployments can only occur on Tuesday I would suggest that you better align your timelines to that fixed requirement.  I can appreciate the argument of the increment being releasable but that condition was modified in the last revision of the Scrum Guide and modifications that are more friendly to Continuous Integration/Continuous Deployment (CI/CD) were introduced.  Here is what I consider the relevant text.

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

However, your company is not using a CI/CD model so you need to adapt your work accordingly.  My recommendation would be to adjust your Sprint boundaries forward 1 day.  Have Wednesday for all of your closing events and activities.  Have the last "working" day of your Sprint be Tuesday so that deployment activities can be part of the same Sprint that built the work being deployed.  If the decision is made to not deploy, that day could be used for refinement activities or some other activity the team determines to be useful. A suggestion for the first one would be to improve the deployment process for your product so that it isn't as cumbersome.  

Thank you all for great explanations. Lets summarize the question and i would like to see all of your opinions.

The comoany has rule that Deployment day is tuesday. Because The deployment occurs in this sequence : Scrum team commits, it goes to Central It. Central It checks the code is suitable to architecture or not. If no, they give advices and turn the task back, if everything is ok, they send to one person for deploying to preproduction enviroment. The team till review has Tested and Everything is OK story in PreProd enviroment.

In Review meeting they gain feedback. The can be feedbacks which PO ignores, or There can be powerfull feedback which makes PO rethink about the story before deployment to Production enviroment. 

Lets suppose, everything is ok and PO decides to Pass to production the story. 

And new Sprint began and in planning, team has a sequence of deployment work which explained above. Should they take Technkcal story of this work in new sprint? 

Scrum team commits, it goes to Central It. Central It checks the code is suitable to architecture or not. If no, they give advices and turn the task back, if everything is ok, they send to one person for deploying to preproduction enviroment. 

This should be part of a corporate Definition of Done that all teams must adhere to.  From the Scrum Guide:

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The organization can create a Definition of Done (DoD) that all teams must follow.  Each team can then add to that definition to add more stringent or pertinent to their product statements.  But if you did this, the organization can then assume that each team will meet Central IT's requirements without them having to be validated a second time.  The deployment work could be documented as part of the delivery and then a member of Central IT could do the deployments as per instructions, calling on someone from the Scrum Team if problems arise. 

The comoany has rule that Deployment day is tuesday. Because The deployment occurs in this sequence : Scrum team commits, it goes to Central It

An approach I've worked to for a range of products:

QA pipeline pushes straight to prod once all quality gates and internal tech change gates are passed.

It is now available in prod. The work is "done." -- that is all the QA and admin is "done."

This happens before sprint review.

- the goal should generally be for this to be continuous per PBI, not a batch (sprint backlog?) at a time. That might well be a core focus for the scrum master for a while.

Sprint review includes the release to production process.

The fact the feature is in production does not mean you need to have enabled it for any users or workload yet: there is a "report that works in the report catalogue" but "only the admins can see it" (not the general user base). It's Deployed. Releasing it is at the discretion of the Product Owner.