There is a slight difference in a user collection, where the collection contains the resourceIDs of the users, that happen to be in a usergroup. That type of collection query requires multiple timings: 1) the user being added to the group, 2) the group discovery occuring (not user discover, group discovery), and 3) the collection update/refresh. Depending upon timing, that can take a while.
The other type of user collection where the defining factor is the usergroup, is where the collection contains one and only one resourceid: the resourceid of the Usergroup. That's the kind I prefer. That way, the group really only needs to be discovered once, initially (and re-discovered on a schedule), but you don't need to wait for group discovery for "new users added".
When you make the User Collection, make sure you select "user group resource" as the resource class, and the collection query is similar to... where SMS_R_UserGroup.UsergroupName = "That Group Name". When the collection updates, there should be only one entry in the collection--even if in AD there are hundreds of users.
The beauty of this type of collection is that CM knows the token sids associated with usergroups that the user belongs to; and upon user policy refresh, it'll deserve policies deployed to this usergroup. So, in the end, let's say Mary Smith is added to "Widgets_3.0" group. Mary Smith simply needs to lock and unlock her console following that group membership add in AD, and CM will know about it, and immediately deserve the policy.
If you do it the other way (the collection ends up containing the resourceid for 'Mary Smith'), that means group discovery, collection update, and then finally policy refresh.