What could be the reason for shrinking the transaction log file before and after the database backup?
Most likely the one who set up that configuration wasn't very experienced with SQL Server.
Or, disk space was extremely valuable, and even though you only reclaim some disk space before it (soon) grow again, the costs and disadvantages of doing shrink was considered lower priority than cost for disk space. Not likely, but a theoretical possibility.
Why a shrink both before and after the full backup? Beats me. A full backup does a checkpoint, which will empty the log (being in simple recovery), so doing the shrink after the full backup would be the reasonable thing to do. If one could use the word &quot;reasonable&quot; when we're talking about regular log shrinking.
I would remove the shrink and add some monitoring. I.e., poll the size of the log every 5 minutes and see if/when it grow.
And, of course, as you state, grow it to some reasonable size. That should probably be your high watermark file size, if you have that information available. Possibly the size before that first shrink - exceptional happenings in your database not counted...