More specifically, it's a parallelism skew. SQL has paralleled the query and parts of it finished faster than other parts.
There's a couple options here.
It could be that the skew has happened because the statistics are outdated and SQL didn't realise how much data it really would have to process. It could be that there are missing indexes and so a query that shouldn't be running parallel is.
The easiest fix is to reduce the maxdop setting for the server and, if this is an OLTP system that may be a good idea anyway. It's not always the best fix.
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass