Use of Shrink after rebuilding Indexes in sql server 2005
Paul Randal answers your question here:


  Data file shrink should never be  part of regular maintenance, and you
  should NEVER, NEVER have auto-shrink enabled. I tried to have it
  removed from the product for SQL 2005 and SQL 2008 when I was in a
  position to do so - the only reason it's still there is for backwards
  compatibility. Don't fall into the trap of having a maintenance plan
  that rebuilds all indexes and then tries to reclaim the space required
  to rebuild the indexes by running a shrink - that's a zero-sum game
  where all you do is generate a log of transaction log for no actual
  gain in performance.
  
  So what if you do need to run a shrink? For instance, if you've
  deleted a large proportion of a very large database and the database
  isn't likely to grow, or you need to empty a file before removing it?
  
  The method I like to recommend is as follows:
  
  
  Create a new filegroup 
  Move all affected tables and indexes into the new filegroup using the CREATE INDEX ... WITH (DROP_EXISTING) ON  syntax, to move the tables and remove fragmentation from
  them at the same time  
  Drop the old filegroup that you were going to shrink anyway (or shrink it way down if its the primary filegroup)