Story points - Clarity

I'm a new Project Manager and learning to be a SCRUM Master.

@Bhuvaneswari Sambandam, Both these roles are at two ends of the spectrum and you may need to start by understanding how different they are. A project manger is not a Scrum Master and vice versa.

Stories in the current sprint get story points assigned during planning session

From my experience and understanding, Sprint Planning should not be the only event when stories can be estimated. This can be done during Backlog Refinement too, however, the estimates can change at the time of Sprint Planning, if more is learned at that time.

Should the team keep re-assessing the story points (reduce daily as per the work completed)? Or should the team leave it as such?

Once the estimates have been finalized i.e. once the stories are in the Sprint Backlog and the Sprint has started, there is no need to adjust it. It can be re-estimated prior to that if needed.

What should I do as a SCRUM Master to keep the team's burndown / velocity tracked right in JIRA

This is the line that made me make the first statement. There is a difference between being a project manager and a Scrum Master. The answer to the above is you do not have to do anything. The progress, i.e. the burndown should be done by the Development Team. The Scrum Master can teach the Development Team how to do this and may remind them why it is needed, but in the end, it is the responsibility of the Development Team.

If a story is being moved from current sprint to next sprint (with 50% completion) should the storypoint be re-assessed to provide a new estimate based on the remaining workload?

A story is either "Done" or not "Done", there is no in between. If the value delivered by the story is still needed, then, yes, in my opinion, it has to be re-estimated. Why? Because, some work is already done and the original estimate is no longer applicable. Estimate for what is remaining to be finished. As much as I have my own questions and debates on this, please try not to move stories from one Sprint to another. This only shows that your initial estimates were wrong or that perhaps the team was trying to be used at 100% utilization.

Also, just because I said your estimates were wrong, it doesn't mean estimates have to be accurate. That is the whole point, its just an estimate. You just need to figure out how to get better at estimation, which happens with experience.

What should I do as a SCRUM Master to keep the team's burndown / velocity tracked right in JIRA

JIRA will create those charts for you based on the Development Team's managing of the stories through the stages reflected on your Sprint Board.  You as Scrum Master do nothing but help the Development Team understand the benefits of managing the Sprint Backlog Items and how to understand the information supplied by the charts.

I had similar reactions to your "Project Manager to Scrum Master" as @Steve.  The two of those roles are extremely different.  So since you are new to both I encourage you to spend more time working on understanding the two before you start focusing on how to do either role's work.  

Should the team keep re-assessing the story points (reduce daily as per the work completed)? Or should the team leave it as such?

Once the story point estimates are made, you do not need to reassess them.  They are a planning tool used by the Development Team to determine how much they feel can pull into a Sprint. 

If a story is being moved from current sprint to next sprint (with 50% completion) should the storypoint be re-assessed to provide a new estimate based on the remaining workload?

How to deal with a story that is not completed during a single Sprint is a topic for debate and you can find that debate in many different postings in this forum. There is no right answer for all, just the right answer for your team.

Stories in the current sprint get story points assigned during planning session

This is one way to assign story points but there are others such as assigning points during the refinement exercises.  Again, many of the postings in this forum have debates on this.  Again, there is no right answer for all, just the right answer for your team.

Again, I urge you to spend more time understanding the difference between Project Manager and Scrum Master.  Project Managers are more command-control where Scrum Masters are servant-leaders.  Because of this difference there are significant differences in how you work. People can do both but they have to understand how their actions differ based on the role that they are playing. 

Stories in the current sprint get story points assigned during planning session

Why is the Scrum Team waiting until Sprint Planning to provide a story point estimate?   How can the Product Owner effectively determine what might be feasible to offer in an upcoming sprint, if none of the items are estimated?   

And who exactly is assigning the story points?

Should the team keep re-assessing the story points (reduce daily as per the work completed)?

Once the sprint begins, story point values should not only be frozen, but they should be completely ignored.   The Development Team has made their forecast - they have their Sprint Backlog.   The story point value has no further purpose, except at the end of the sprint, to tally up the story points for all of the "completed" items for a team's velocity metric (used for planning purposes only, and not as a performance metric).

What should I do as a SCRUM Master to keep the team's burndown / velocity tracked right in JIRA

As a Scrum Master, you should help the team understand the value of a burndown chart for assessing sprint progress, and teach them how to set it up and maintain it.   If you're using a tool like Jira, such charts are readily available.   Try to avoid the urge to perform anything that could otherwise be done by the team.

If a story is being moved from current sprint to next sprint (with 50% completion) should the storypoint be re-assessed to provide a new estimate based on the remaining workload?

If an item is incomplete by the end of a sprint (try to avoid any discussion of % complete!), it should be placed back into the backlog and re-estimated based on the work remaining.   It may very well be offered by the PO for the next sprint, but not before these steps.