Timely completion of tasks

Daily Scrum and Sprint Goal.

The completion of tasks should not be the focus of the Developers. They should be focused on doing the work needed to satisfy the Sprint Goal.  The Daily Scrum is the event where all of the conversations associated to that occurs.  The Developers should focus on completing work rather than starting a bunch.  Often I see that the Developers look at a long list of tasks and they feel pressured to complete them all.  As a Scrum Master it is our job to help them understand that completing tasks is not the focus.  Completing work to support the Sprint Goal and deliver a usable increment of value is where the team should focus.  It's a mind shift.  The Developers will no doubt argue that "all the tasks have to be completed in order to reach the Sprint Goal". 

My team is struggling to complete their tasks as per the estimations due to some blockages/dependencies.

That statement is a clear indicator that this is occuring. If that is indeed the case, maybe they need to adjust their expectations on how much work they can do in a single Sprint and try scaling back.  The primary driver for that approach is that when they created their estimates, they did not know all of the information they need.  As they start to work, new information will be discovered and adaptations may be needed.  That is the reason for iterative work in the Scrum framework.  To be able to make empirical decisions as new information is found.

 We have started keeping due dates on the respective tasks in Jira

That is the reason for the pressure.  Whoever is driving that behavior is indicating that the work is time based rather than value based.  

What can be a simpler solution to track the timely completion of tasks without the team feeling pressurized?

How about not tracking completion of tasks and letting the Developers concentrate of completing valuable work.  

Daniel has a lot of good comments, but I'll also add something else.

It seems like you are treating the team's estimates as deadlines. An estimate doesn't tell you when work will be done, just something about completing the work. It could be an idea of when it will be completed or an amount time that needs to be spent working on the task to complete it or how much effort is needed to complete the task. None of these are deadlines or represent when the work must be completed.

I would recommend focusing on goals and making steady progress toward completing those goals.

My team is struggling to complete their tasks as per the estimations due to some blockages/dependencies. 

Was this work sufficiently refined and made ready?

Product Backlog refinement is the art and science of de-risking work before it is planned into a Sprint. Any significant dependencies which will need to be managed ought to have been surfaced so their mitigation can then be allowed for.

When a team enters Sprint Planning, the question should never be "can we do this work?", but rather one of "should we do this work in order to meet a good Sprint Goal?" When work isn't ready, the Sprint Goal commitment is put at risk before the Developers have even begun.

Thank you for your feedback. appreciated. As per the comments Let me try the approach of reaching sprint goal than completing tasks. Also as rightly mentioned by Thomas I was treating estimates as deadlines which should not be the case.

I will definitely follow everyone's comments to improvise.

Does the team have a clearly defined "Definition of Ready"? I think that could be very useful here because if this a recurring pattern, I would suggest really taking into account these 5 factors in your story refinement:

1. Risk

2. Complexity

3. Dependencies

4. Business value

5. Amount of Work



If any of these factors are unknown or not fully understood by the team, then it's safe to assume that story is not "ready" to be worked on