You want to consider these things carefully before you go implementing them in your maintenance plan. I usually ignore the shrink settings in the maintenance plan, particularly for the TLs.
Originally Posted by inka
For data files, as a general rule I like to keep about 20% free space and let them auto grow up to about 15 GB. once past this threshold, I usually turn off auto grow and manage the growth manually during scheduled maintenance windows. I usually do not shrink my dbs unless I do a major data purge that frees up a very large chunk of space. Expangding a datafile is a very costly activity and can hold up insert/update statements. Why routinely shrink a db that is (generally) going to grow in size anyway?
For transaction logs, I like to try to keep the physical size relatively constant and schedule log backups to occur frequently enough to prevent the log files from filling up completely. Same reasoning here: the process of expanding a log file is expensive in terms of host resources and it is something I would prefer to avoid.
If you are talking about small (<100 MB) databases on development servers, the story might be different. But in that case, why would you need to conserve the space? Performance does not improve with file shrinkages. It's not like running a defrag...
Have you hugged your backup today?