I don't want to get too hung up on process detail here (what "boards" you have/need what you call them etc etc) as we are only looking at a tiny snapshot but I would expect a bit more sanity within your process than "formal" approval at such a granular level ............
The "work" (and business need etc) for Feature A and Feature B has been approved (seperately or together)..............
This implicitly included (any) work needed for Common Bit (possibly twice)..........
If you weren't doing Feature B at all - you'd still need to do Common Bit (logicall there would be no seperate Common Bit to need approval) so whatever approval/authorisation you have MUST be OK.
The segregation/seperation of A from B is only a "technical" issue....
Obviously when you come to implementation (assuming they don't "go together") you have one less task for the Feature that goes 2nd (as Common Bit has already been done).
This is assuming that Common Bit is fairly trivial (Features A & B may or may not be - but it doesn't matter "much" as they have been justified already)
If Common Bit is in fact the major part of the change (with the features being trivial)
eg Common Bit is implementing a full Database schema and Feature A & B are trivial SQL reports
then:
a) You would appear to have saved a fair amount of resource - as the major work for Common Bit has been justified/costed and approved (twice).
b) You should possibly look at your Impact Analysis process..........
