Priority of Task

@Samad Mustafayev, The low priority Product Backlog Item does not have to be "very detailed", it just needs to have enough information and the Development Team should have enough understanding to undertake the work.

If the information is not sufficient, how did the Development Team members agree to complete it? If the information is not sufficient, in your opinion, if you were in that situation, what do you think should be the next logical step?

What exactly do you mean by "very important"?

A few things stand out.

The ordering of the Product Backlog is not simply based on importance, but rather maximizing value. For example, it may be more valuable to do "less important' work because it can reduce the risk associated with the technical direction of later work. To an external stakeholder, the work is less important. However, to the Development Team, this could let them vet out and get feedback on how their technical solution will work when applied to more complex or critical parts of the product being developed.

Dependencies also matter. Sometimes, work that may be seen as less important needs to be done first since it enables the other work to be valuable. Sometimes this is more out of convenience rather than a technical necessity, but changing the order can mean both things are delivered in less time than it would take to do one if the ordering was changed.

If the work suddenly changed importance to a stakeholder, I'd be curious as to why it changed so rapidly (and if this was seen as a possibility by the Product Owner). I'd also be interested to know why they couldn't wait until the next iteration to start it. Depending on how frequently this is happening, it could be a sign that the Sprint cadence is not appropriately synchronized with how often the stakeholders gain an understanding of their need and the Product Owner updates the Product Backlog to reflect this understanding.

There could be plenty of things happening, but I believe that it is important to balancing this changing landscape with the ability to have an intense focus on the current Sprint.

If the customers re-prioritize a low-priority item to a high-priority item during a Sprint, there is no problem regarding DoR so far.

In that case the PO should change the priorization in the PB to bring the PBI up. And with the new priority it may need to be detailed and refined, so that it is Ready for the next Spring Planning. And only in the next Sprint Planning it may be added for the next sprint.

Agile does not mean that we jump as soon as the customer is asking for something. We commit a certain Sprint Goal, to be completed in a time-box. And we do not accept new tasks that may endanger the Sprint Goal. And once the Sprint is done, we may react on changes.

During the sprint, a low priority task which is located at the bottom of Product Backlog list suddenly becomes very important for the creation of product, but the problem is as it was low a priority task( which was not very detailed or well explained) it does not fit the Definition of Ready for Development team. What should be done in this situation and who must correct it for the developers?

Is there any reason to suppose that this information would be ignored in the Sprint Review?