I think, creating effective Sprint Backlog is one of the most critical task for any sprint to achieve its purpose and goal. If done effectively, can do wonders for any team and project.

One effective way of creating Sprint Backlog can be combining Velocity driven approach and Commitment driven approach.

Pick up as many top stories as necessary for the sum of story points estimates to equal the team velocity (this is velocity driven approach). Identify the team capacity, of how much each member is available during the sprint. Sum up the total available hours for all team members. This becomes the team capacity. Then each selected story is split to tasks and each task is estimated in hours. Now when the total task hours become equivalent to team capacity, then team can decide to commit only for those stories (this is commitment driven approach). If picked up stories are still left then it can go back to product backlog to be picked in next sprint and if less stories were selected then team can start adding more stories, splitting them into tasks, estimating them and matching the total estimated hours with available capacity.

Both approaches when combine helps in forecasting if team is available and will be able to deliver as per last sprints or if team velocity is going to decrease or increase. With the condition that team composition is not changing for the entire project, it provides team one more chance to look at the reason for decreasing or increasing velocity just at the beginning of the Sprint. So team knows the velocity beforehand (at the start of sprint), team should be able to achieve in the given Sprint, but this calls for how effectively team capacity is done. Teams should make sure to spend hours working on sprint which were taken into account while calculating Team Capacity. Many times, team members does not exclude meeting time, break time and time spending in any other activity which is not part of sprint, they just give the actual office time. And to have the effective team capacity, each team member should specify only those hours which they are expecting to spend ONLY for sprint work. This ensures that calculated team capacity hours are the hours team is going to actually spend only working for Sprint.

In a nutshell, combining both these approaches help in providing much more accurate forecast the amount of work team can do along with the reality check on the reasons for the increase or decrease in velocity. Thus ensures to capture the real essence of following SCRUM methodology by achieving the sprint goal and delivering shippable product at the end of every sprint.