Suggested Reading:

Scrum Overview ( a longish guide from the Scrum Alliance )
ScrumMaster
Product Owner
Sprint Planning Meeting
Sprint Retrospective

I've setup this Scrum Board in JIRA.

Members:

ScrumMaster
Product Owner(s)
Testing Lead ( and any other testers wishing to join )
Developers
Documentation Writers ( if they wish )
Bug Wranglers ( if they wish )
Anyone wanting to take on tickets

Anyone is allowed to join the meetings, but only those willing to take on work assignments can participate.

Call should be at least an hour, with half hour for retrospective ( closing a sprint ) and planning ( starting a sprint ). The first half of the meeting is a retrospective, where we go over the work the was completed, not completed, and rejected. This is also where we can talk about things that are working or not working or need improving. Second half of the meeting, we plan the next sprint.

Prior to the call, the Features Prioritization team will have gone over the project backlog, and prioritized a collection of features and bugs to be at the top of the list.

I would suggest using quick filters, so you can have multiple backlog lists ( for example, I've created a "public_interface" filter, so we can toggle to that list when we want to consider PUI work ). Also, it's a good idea to have about 2 sprints worth of tickets prioritized, in case we run through a bunch during the meeting.

The planning session starts with the ScrumMaster going through the list of tickets in order, asking the PO questions to clarify. Tickets do not have to be totally specified before the call, but it would be appreciated ( we can do it during ). Teams member have the chance to ask questions, voice concerns or support, etc. The Scrum Master and PO will both try to document the "What does done look like" for each story and bug, so that everyone is on the same page ( PO, developers, testers, etc )

If someone agrees to take the ticket, it will be dragged up into the sprint and assigned, The assignee will estimate the amount of effort required to complete the ticket.

The point system is : 1, 2, 3, 5, 8, 13

A 1 is a low effort job and a 13 is a "this is all a full-time developer can work on for this sprint" type of job. Participants can express how many points that are willing to make available for a sprint.

The sprint is planned once all the participants have filled up their point quotas or the meeting has run out of time.

Browser not supported