Here is a rough sketch of the pattern:
Context: A well defined Product Backlog and a Scrum Team and a Scrum Master.
Problem: A specific way to break down the Product Backlog assigned into the Sprint into tasks that can be estimated, assigned, tracked, and reported.
Forces: size of the task, complexity, priorities, value.
Solution: Translate the selected portion of the Product Backlog into a Sprint Backlog by letting the developers choose what tasks they want to be responsible for, while making sure they are collectively capable of completing the work. Only some percentage of the Product Backlog is translated into tasks at the SpringPlanningMeeting, because some of the tasks will have to be defined as the ScrumTeam learns or knows more. The Sprint Backlog is updated during the Sprint as new tasks are discovered, refactored, deleted, and if there are any tasks left at the end of the Sprint, it is preferable that they all belong to the same Product Backlog item. That way these tasks can be transferred to another Sprint.
Resulting Context:The ScrumTeam has an instrument to measure its progress (see problem).