When the database recovery model is set to FULL or BULK-LOGGED, the database and the transaction log are handled completely separately.
Thus, backing up the database does not free up the log; you must still back up the log as well to re-use it.
Vice versa, if the log file is too large for your liking - but see below - resizing the data files does nothing; you must explicitly back up and then shrink the physical log.
HOWEVER, do not use auto-grow just because it looks convenient! There are serious penalties for having a multi-gigabyte log file that was grown in 10MB increments, well-documented at the microsoft website.
In a nutshell, growing or adding to the log will divide the space added into a number of new virtual logs, from a few to a dozen - every single time this happens.
When your transaction log has grown from 10MB to 1GB in 10MB increments, chances are it will be fragmented into a thousand virtual logs; this hurts performance.
My advice is to calculate - or observe - how much transaction log you need between log backups, double that, and set your log to that size.
Then disable autogrowth and implement monitoring on log utilization so it warns you when it gets above 90% or so.
It is far better to manually add a few 100MB every once in a while, thus keeping the fragmentation to a minimum.