There's nothing wrong with asking academic or homework questions, but asking questions where you haven't put any effort into solving the questions yourself is frowned upon. Furthermore, homework questions don't always have canonical answers because the only "right" answer is the one your teacher is looking for.
With that said, the questions you're asking are worth answering for two reasons:
- They're relatively common questions, and good answers will provide worked examples.
- They highlight a lot of common misconceptions, and understanding why the questions have some misleading and/or incorrect assumptions is worth pointing out.
My answers below will help you answer your homework questions more knowledgeably, but may or may not be the answers your teacher expected you to provide. Your mileage will therefore vary. Good luck with your assignment!
Calculating Velocity for Sprint and Release Planning
What's Your Velocity?
For velocity values of 15, 5, 20, 15, 25, 10 you have a median velocity of 15. There is a 90% likelihood (technically, a confidence interval) that your actual velocity for your next Sprint will fall between 5 and 25.
See the Velocity Range Calculator for the math behind this calculation. You can do your own calculations with a different confidence interval if you prefer.
What's Your Planning Capacity?
You can select any mix of stories you like, provided the total is less than the team's expected capacity and that the stories selected all relate to the current Sprint Goal. Without any fudge factors or discussions about risk tolerance for an unmet Sprint Goal, then I'd assume 15 story points as a reliable target give or take a small story.
Scrum Isn't a Knapsack Problem
Sprint Planning is partly a knapsack problem, but is further complicated by the requirement to select stories in priority order from the top of the Product Backlog and to ensure that all selected stories contribute to (or at least, don't detract from) the coherence of a singular Sprint Goal. That's why the Development Team and the Product Owner are encouraged to discuss stories and do some horse trading during Backlog Refinement and Sprint Planning meetings: to allow the Product Owner to edit and reprioritize the Product Backlog on the fly to optimize stories for team selection.
Story Selection Isn't Free-Form
The team can't pick stories based solely on size estimates, nor should stories be selected based primarily on trying to maximize the number of story points for the Sprint. In Scrum, stories must be selected by the team in strict priority order from the Product Backlog until their expected capacity for the Sprint is allocated, but it's the Product Owner's job to make sure that priority order reflects a central coherence for the Sprint.
Optimize for Cadence, Not Velocity
Accepting stories based on ordinal values up to (but never beyond) the team's capacity forecast may sound counter-intuitive, but it really shouldn't. Pragmatically speaking, Scrum teams optimize for coherence and a reliable cadence rather than velocity for its own sake. Velocity is just a proxy for capacity to assist with forecasting.
Algorithm designers strive for optimal solutions to the knapsack problem. Scrum teams strive to deliver value at a reliable cadence. Too much focus on optimizing velocity is a distinct anti-pattern.
How Long for Entire Product Backlog?
You have 30 story points remaining in your Product Backlog. Assuming you have estimated accurately and that no estimates change over the remainder of the project—teams are expected to re-estimate based on new information during Backlog Refinement and Sprint Planning—and also assuming that you don't add or remove anything from your Product Backlog over the next two Sprints, then at your present velocity it will take you at least two Sprints to complete the entirety of current backlog.
What's Your Worst-Case Scenario?
Note that since a Sprint provides a potentially-releasable increment at the end of each iteration, it's possible that the project can be declared sufficient and be closed out after the current Sprint. Alternatively, if your team delivers less than the median (your confidence interval has five story points as your low-end forecast) then it may take up to six Sprints to complete the entire Product Backlog as currently constituted.
While the real worst-case scenario is always:
- no work completed per the Definition of Done,
- a failed Sprint Goal, and
- a velocity of zero for the current Sprint,
based on statistical probability you have a 90% chance of getting at least five story points done in your next Sprint. You have to recalculate your probabilities each Sprint, but for forecasting purposes six Sprints is a reasonable outer bound given your data.