Sprint work before Planning meeting

Sprint Planning meeting should be first thing in the Sprint and not in the afternoon or the next day.

That is correct.

Today there are many items regularly rolling from Sprint to Sprint...usually half of what was planned.

Does the Development Team have a definition of "Done"?  Are you their Scrum Master?  In the Sprint Retrospective have you reminded them that the most important concept they are missing is to deliver a "Done" Increment every Sprint, and ask them for ideas on how they might accomplish this?

Pre-Planning meeting - During the week prior to the Sprint

Sprint Begins - Monday morning

Sprint Kickoff Meeting - Monday afternoon (or Tuesday afternoon for some teams)

There is no pre planning meeting in Scrum, but there is the concept of Backlog Refinement that can make enough "ready" Product Backlog items for the upcoming Sprint, and may help.

Read up on the Scrum Guide, it will help you.  In fact, one idea you might try is to have your team read the Scrum events section, and pair up and teach each other.

Thanks for the reply.  Today the team has no ScrumMaster, that is the role I will be filling here in a few weeks.  So the current state of things is due to years of evolution without retrospection.

I like the idea of getting the team to read up on Scrum events.  My thinking is that this has to start by getting to basics.

I was also asked what does QA do while waiting for tickets from developers (there are dedicated QA resources in the team).

As the Development Team how they could lesson hand-offs between a a developer and a tester, and how they might move closer to being more cross functional, over time.

Might the tester start writing tests, and thinking about how they might automate tests?  Is there an opportunity for the tester to pair up with the developer from the start? 

Pre-Planning meeting - During the week prior to the Sprint

While this is not an event covered in the Scrum Guide, I have worked with a couple teams where this practice benefited them.   It is just a brief touch point - if you're familiar with the headlight analogy (only focused on near-term goals/objectives), think of such a meeting as a quick glance at the map and the road in front of you.   Such an opportunity to review a potential sprint offer allows the Development Team a chance to come up with concerns/questions in advance, and helps mitigate risk that way.

Today there are many items regularly rolling from Sprint to Sprint...usually half of what was planned.

To me, this is what stands out as the most serious issue facing this team:   

• Why is the team consistently missing their forecast?   
• Is the team accepting items each sprint, or are they being pushed to the team?   
• How is it even possible for the business to plan/forecast when they have little if any certainty around what might get finished within a sprint?
• Has the team reflected at all on why they're consistently carrying incomplete items from sprint to sprint?   If so, what are some of the identified root causes, and can the Development Team do anything about them?   If not, why not?
• Has the team attempted to forecast much less work in a sprint, and to possibly "pull" in additional items during a sprint as capacity dictates?

To me, it seems this "Team" has operated for years under SINO (Scrum In Name Only) without either the Development Team or the Product Owner (Business) being able to roughly estimate the amount of work they can realistically complete within a sprint. 

I like the idea of getting the team to read up on Scrum events.  My thinking is that this has to start by getting to basics.

My advice is to start with the Scrum values before heading off into the mechanics of events, roles, or artifacts. Considering the issues the team face, it might be wise to begin with commitment and focus.

Hey Chris - some thoughts:

• "Pre-Planning meeting - During the week prior to the Sprint" - consider running regular (once or twice a week) backlog refinement sessions for the team 
• "Sprint Begins - Monday morning" - consider starting sprints on Tuesdays. Many team members like to get time off at the end or the beginning of the week
• "many items regularly rolling from Sprint to Sprint...usually half of what was planned" - you should first identify the reasons for this situation... is it underestimation? overconfidence from the team, grabbing more than they can chew? PO pushing for lots of work? change in requirements/scope during sprint? story swap? major production impact (bugs) that needs to be addressed? lack of adequate QA?  etc Once you identify, take actions towards fixing. Setup a meeting with the team to create a DoR and a DoD. Reduce the sprint lenght to allow for faster feedback.
• "I was asked what developers are expected to work on before the Planning Meeting (if it replaced the current kickoff)" "I was also asked what does QA do while waiting for tickets from developers (there are dedicated QA resources in the team)" - management not trusting their staff? Seems so. Developers and QAs participate in all Scrum meetings, including backlog refinement. Once the sprint starts, I'd say there could argument to be made that QAs won't do much during the first day - since the devs are just starting, but since the dev tasks should be one day or less, from day 2 things pick up. Also, QAs and devs should work together, DAILY, towards ensuring progress is accurate. In other words, testing is an ongoing process (goes hand in hand with coding), not something you do at the end of the sprint (like, say, regressing testing).
• "Today they spend that time working on the items that rolled over and they begin development work sometimes even before the next sprint has started." - there should be no rollover. At the end of the sprint, Done items are Done (and may be released to production environment). Items not done should be reestimated and added to the backlog for further consideration by the PO and the whole team. Just because a story was included in sprint X, and wasn't completed for whatever reason, it doesn't mean it should automatically be included in sprint X+1. It has to be reviewed against business priorities and compared with other valuable stories for the PO. The PO will know.
• "My best answer to the question was making sure backlog items are ready to go (sizing, user stories, test plans) which is a big problem for the team today" - indeed. Like I said, you'd need a DoR in order to bring clarity and transparency in terms of what stories are ready for sprint planning consideration. Usually, the flow would be along the lines of: user story created > refined > estimated > ready for planning. If, after estimation, the story is updated, it has to be reconsidered, and even reestimated if the team believes the changes are significant and therefore the effort is different (higher or lower).

Hope this helps. One question for you: how often do you release? Once per sprint? Multiple times per sprint?