Shrinking the log file does not reduce size

Here is the answer to my own question.

Run the below query to get information about the log file's reuse wait:

SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = 'DBName'

I got the following output:

log_reuse_wait_desc
-------------------
REPLICATION 

There were some replication-related objects remaining in the database, even after removing the replication.

To remove the replication from the database, sp_removedbreplication can be used. But it didn't work for us as replication was not active at the time and actually replication had been removed long before.

The solution was to import the database contents to another database using the import option of SQL Server.

Read How to Shrink SQL Server log for an explanation how the circular nature of the log may prevent shrink after truncation. Is possible that you log's last LSN point into a VLF that is at the tail of the LDF. Counter intuitively you must advance the log, by generating log writes, to allow it to shrink.

Steps for shrinking the log are going to be

Backup transaction log through either SSMS or T-SQL and then perform a shrink

commands for SSMS are under the tasks if you right click the database name

BACKUP LOG <Databasename> TO DISK N'<path\database_log.ldf';
GO

DBCC SHRINKFILE (<FileName>, <TargetSize>) WITH NO_INFOMSGS

You will probably have to do this multiple times

If there is a transaction or job blocking the action, use Activity monitor to identify the process and kill it, or use the SQL Agent job activity monitor to end the job.

source: http://support.microsoft.com/kb/907511