Short version: You set delegation options for a security principal (i.e. user or computer) you've just configured an SPN for on the Delegation tab of that principal in AD Users and Computers.
Longer version: No, no, no!
You don't want to set up Kerberos Authentication and therefore delegation. These are separate concepts, independent of one another.
You can authenticate using Kerberos without needing to delegate anything. In fact, out of the box, Windows 2008's IIS 7 and later ship with a default configuration which means that any single domain member box, where its real hostname is used, will be able to perform Kerb authentication. See "Kernel mode authentication", and, spoilers! You'll need to turn that off for your scenario to work as you've described it*.
Kerb Delegation requires that one principal be used to terminate one Kerberos-authenticated hop, and then perform another, on behalf of the original requesting security principal (the user).
Back to the solution:
So for PC -> IIS -> SQL, you'd need to map out who each process is running as:
PC (user) -> IIS (App Pool Account(IISApp01)) -> SQL (Service Account("SQLService"))
In this scenario, every account must be a domain user account, and for simplicity, you need to disable Kernel Mode Authentication in your Windows Integrated Auth options for the website in question.
Then, you need to identify the SPN used at each hop, and ensure it's registered with each one:
PC (user) doesn't matter
IIS tier: SETSPN -S IISApp01 http/name.used.by.client
(this is never automatic)
SQL tier: SETSPN -S SQLService mssql/name.used.by.iis.app:1433
(this may have been automatic)
then, you should have a Delegation tab available for IISApp01, on which you can specify that IISApp01 is trusted for constrained delegation to (Search, pick SqlService, then pick the appropriate SPN registered against SqlService).
There's a website/program called DelegConfig available which helps map this stuff out for you.
*not strictly true; there are many solutions.