Can anybody answer my question here? I have estimated for 5 to 6 tasks like analysis (4 hrs), design (3 hrs), logical review (1 hr), peer review (1 hr), unit testing (1 hr), coding (2 hrs) and release (1 hr). But during analysis itself I came to know that rest of the activity will not be applicable. In this scenario, should I make the hours zero for all the tasks that have become obsolete or should I delete the tasks?
Use research stories to minimize uncertainty
As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
So, if you have determined that some of the tasks are not necessary, remove them.
@David Arno suggested approaches for filling the gap in the Sprint. However, if this frequently happens or if it is a major part of your Sprint, you should consider doing a time-boxed research story (also known as a spike) in a previous sprint. The same analysis, possibly including a minimal proof-of-concept, will allow you to plan with more confidence.
Delete the tasks.
If you find yourself writing the same tasks like j-unit, dev testing, etc for all your stories/backlogs, they are not tasks, they are done criteria and can be rolled into a higher level task such as "implement XYZ as part of the solution."
Try and minimize the overhead associated with creating and managing task level details within the iteration if it is not adding any value.
The first point to make is that I'd suggest you are breaking your tasks down to too fine a detail and are creating a mini waterfall within your sprint. Unit testing and coding are typically done at the same time, so having two separate tasks will likely cause problems. If you adopt TDD principals, the act of writing the tests and developing the code is the design etc.
Having said that, your tasks are what they are. If one task has rendered others irrelevant then, depending on circumstances you'd normally do one of the following:
If there are plenty of other tasks assigned to the sprint, then just remove the unneeded ones from it. Then discuss with the scrum master and product owner whether it's possible to add other tasks (from the backlog) to the sprint instead.
If the tasks to be removed make up the bulk of the remaining sprint, then advise the product owner that the sprint should be abandoned and the end/start sprint meetings should then be bought forward and a new sprint planned.