You're talking about two different things here to me - shrinking the log file(s) is quite different to truncating the log.

Obviously if you truncate the log and use a recovery model that relies on the log files for recovery then you're dead if you don't backup the Db after doing a truncate log operation. 

If what you are doing is shrinking the log file then in some cases you need to "rotate" the virtual logs inside the log file to allow DBCC SHRINKFILE to actaully shrink the log file. When I've had to do this I always get an application outage, lock out other users, backup the db (full) then perform the log shrink, then do another full db BU, check things out, then make the db multi-user again - sue me I'm an anal DBA - data protection is paramount to me.

I hate doing log shrinks so I generally try to design or encourage the developers to design the db and db code and operations such that the log doesn't grow to such an extent - not always easy I admit. 

Regards,

Stu