Ideally, before performing the Sprint Planning session as a team, the Product Backlog Items those will be potentially included in the next Sprint are supposed to be estimated in Story Points. The higher the priority of any Product Backlog Item, the higher is the expected maturity level of that particular PBI. Then, based on the average velocity data i.e. the average completed story points in the past, together with the expected capacity of the team for the next Sprint, the development team decides which PBIs should be included into the scope of the following Sprint. We, as the product owners are supposed to provide the right level of priorization and the overall direction to achieve a Sprint Goal before the planning session. This is basically how Sprint Planning works.
Nevertheless, Scrum teams may face scenarios where there may be strict deadline for a new feature or a solution. In other words, teams could face circumstances where the typical release planning could be not be applicable. To make it more concrete, let’s assume that the total amount of Story Points for a new to-be-developed solution is 100 SPs. Moreover, assuming that based on the proper planning done by PO according to the velocity of the team while preserving the projected capacity , it seems feasible that the team would require 4 Sprints in order to ship the solution. There are chances that, due to a certain reason ( Top Management expectation, natural deadlines such as Christmas, back-to-school season etc.) it may not be feasible to run 4 Sprints as the strict deadline does not allow such a period of time. Let’s imagine that for this example the deadline is just 3 Sprints away. Than the big question is how should a PO react if she/he encounters such a case ?
As a general project management rule, each project has been performed under 3 constraints which are cost, time and scope. In our case, we can’t play with the time constraint as it’s fixed. What can be done is either stretch the cost or shrink the scope. Depending on the nature of the delivery, scope could be optimized if the granularity of the duty allows it. From my perspective this should be #1 option to make it happen. In other words, as POs we are supposed to secure that the user stories are fine-grained to a level so that a portion of the total task could be delivered as a new iteration just following the deadline without impacting the business value much. If it’s not feasible to delay even a small part of delivery, the second and only remaining alternative is to bear an over budget case which is basically an increased amount of efforts of the development team. This translates to either empowerment of the team or the team is doing overtime. Once again this should be really the last resort since it would cause the development team gets overwhelmed and in return under-deliver in the following sprints.
In essence, if you as a PO face cases where there is a fixed deadline and the required effort to ship the expected software with the right level of quality seems not fit to the time schedule, you’d better make a right re-prioritization by breaking down the requirements into fain-grained tasks, decide the ones those could arrive later and perform a tough negotiation with your stakeholders.