When scoping/planning development work for the engineering team the first question from the developer is always: When does this have to be done? How long have we got? Generally these deadlines are never met and it's always accepted that a software development project will go beyond the given allocation, it's rarely launched before/on time.  The developer may deliver on time however it's generally not what the business initially asked for and requires round(s) of changes. There are obviously methodologies to help avoid this(we have used shape up for the last few years with good success - https://basecamp.com/shapeup) 

Appetite is recorded against a pitch as to how much resource(time = money) the business is willing to allocate for a given feature.  It's used as a circuit breaker, if the project goes beyond the appetite then it is under consideration for one of the following below.  

It's up to the necessary stakeholders to get together and decide the next steps based on work completed VS work done.

The appetite is not the amount of time the engineer(s) have to devote towards a pitch.  The value of the appetite should not affect the approach.  The approach is always the same regardless of the appetite(2 hours, 2 days, 2 weeks or 2 months).

Example of this might be the following:

Pitch: Create a Blog for Company X
Appetite: 1 Week
MVP:

The core functionality of a blog is creating and viewing posts so this is what the engineer should concentrate on first.  Once that is done the engineer is pushing progress to the review app for feedback from the business.  At this point we have a working version that could be considered a blog( 4 hours work Vs the 1 week initially recorded as the appetite).  It may be good enough to push as is, it may have to wait for some other features before it's considered good enough to launch.  The other requirements mentioned in the pitch may or may not actually be required for initial launch or at all.  The business may be happy with the MVP and decide other pressing matters are more important. Following this approach means no time is waisted thinking about requirements that are not in the core set before actually tackled.

Development Cycles
For a development cycle and engineer may have 1 or more pitches to develop within the given period(4/6/8 weeks). Its expected once you have the MVP for pitch 1 up for review that you can potentially move on to pitch 2 while awaiting feedback.  The landscape is alway changing so getting quick feedback allows the business to adapt to changing needs.  It should be clear after the initial core requirements MVP as to what to focus on next and what amount of effort to devote in total.  Scope can normally be cut at this stage, the business will be eager to launch after seeing the quick turnaround and smaller(nice to have requirements) can be put on ice.

Obviously the above will depend on certain situations however the key message is: