Sprint Planning

As a Product Manager, Sprint planning is a balancing act. It is finding a right mix of items from,

Feature Backlog - Maintaining a active list of feature backlog is critical. The input to this list could come from variety of sources - Customer feedback, Competitive Gaps, Product Roadmap, Engineering feedback etc. Prioritizating the feedback in terms its impact and cost will be helpful prior to sprint planning.

Backlog Bugs - Active bug list is just the nature of software development process, again it is important to keep the bug list prioritized so that it can be appropriately assigned to a sprint.

R&D - A sprint activity cannot be just development of new features and fixing bugs. Certain activities require investigation and may not end with something that is shippable in the sprint.

Out-of-scopes - These are unplanned feature requests or changes that have solid business justification. Again this is the nature of software development process to have change requests come in during the middle of development.

Now let us look at allocation for the above. The allocation may vary from kind of products, but this is the model that I follow,

Feature Backlog - 50%
Backlog Bugs     - 10%
R&D                   - 10%
Out-of-scopes     - 30%

The next step is looking the team capacity. This is simply number of  developers & QA available for the Sprint cycle. As an example, if you 10 developers and 5 QA available and the Sprint cycle is 2 weeks, the total available capacity is 30 man-weeks.  Now spread this capacity as per the allocation model above,
Feature Backlog - 15 man-weeks
Backlog Bugs     - 3 man-weeks
R&D                   - 3 man-weeks
Out-of-scopes      - 9 man-weeks

Now go back and estimate the cost (man-weeks) of the prioritized feature backlog. Then it becomes easy to decide which features can fit because we've already estimated the allocation for new features.