The default trace holds some limited information about all DBCC commands, including shrinkage. Using Aaron Bertrand's query as a starting place, we can figure out which database was shrinkaged, and then look at some recent backup history for it.
WITH p as
) + N'log.trc'
FROM sys.traces AS t
WHERE t.is_default = 1
) s (p)
) - LEN('''')
CROSS APPLY sys.fn_trace_gettable
) AS t
WHERE t.EventClass = 116
AND t.TextData LIKE 'DBCC SHRINK%';
You need to do a little gymnastics to parse the DBCC command, because the database that gets logged in the trace is the one that the command ran from, not ran against.
Note that I'm including some columns from the trace that I believe will always be NULL for shrinkages, but it could also just be something with what I did to generate test data in the trace that made them less than useful. If they're also NULL for you, well, you're in good company. But I can't make them more useful.
If you need help understanding what the string parsing did in my query did, you can check out my post about it here.
Once we have that tucked away in a #temp table, we can look at full backup history for the database.
FROM #p AS p
SELECT TOP (20)
FROM msdb.dbo.backupset bs
WHERE bs.name = p.ShrunkenHead
AND bs.type = 'D'
ORDER BY bs.backup_finish_date DESC
) AS bs
With that, you can get some idea of how the database backup size changed. I'm including regular and compressed sizes, just in case.