What to do with a tasks that will be performed between 2 sprints (i.e. demoing at an event)

What are you actually using story points for? How would you describe their purpose and what value do you discern in them?

We use story point to assess the performance of the team. I look at them quite in a flexible way.. if we conclude with 27/30 I think it’s fine. But they really look forward completing them all (sometimes I question the quality of work..not sure that it’s totally beneficial being so competitive about it). We assign story point through a combination of effort and difficulty of the task. But mainly we all vote to assign them and it pushes us to all understand the objective of the task (I.e if there is too much difference in the assignment of story point it means the story  is not described clearly enough).

We use story point to assess the performance of the team.

That is a very bad smell in Scrum.

Story points can be gamed.   If you make story point completion (number, percentage) as something the team will be measured by, you are effectively telling the team to focus on story point completion, and not on delivering quality and value.   You've even observed such behavior!

Relative estimation (i.e. - story points) is meant as a planning metric to assist the Product Owner and Development Team to assess what can be reasonably forecast for completion in an upcoming sprint, considering team capacity and past results (velocity).  Once the sprint starts, the Development Team should ignore the points - they have their forecast!

Story points are also an output-based metric, which may provide some insight into the effectiveness of the team, but tells you nothing about whether they are delivering value to the business and delighting the customer/end-user.   You need to develop outcome and impact-based metrics that inform you about the quality and value the Scrum Team is producing.   

Right now, you're just measuring the amount of "stuff" they're producing (whether it is quality stuff or not).

Hi Timothy, I totally agree with you. For me, they are a way to understand we are all aligned in the forecasting of effort and time and clarity of scope. But yes, the fact that we report the completion of "story points" eventually it becomes a competition with the risk that quality of work is not taken as a priority.

What would you suggest as parameter to track the performance of a team?

Coming back to my question, what would it be your approach with a user story that goes across 2 sprints?

Would it make sense to just have the story progressing in 2 sprints? Or should I split it - even though I could not close the first one after one sprint?

What would you suggest as parameter to track the performance of a team?

Are the team meeting their Sprint Goals, and delivering useful increments of work every Sprint that are of release quality?

Would it make sense to just have the story progressing in 2 sprints? Or should I split it - even though I could not close the first one after one sprint?

Do you think that the INVEST criteria might prove helpful when defining good stories?

What would you suggest as parameter to track the performance of a team?

I echo Ian's reply around meeting Sprint Goals and forecasts, and producing high-quality and valuable deliverables.  I would also want to know if they are actively trying to improve/experiment.

Considering your question is about the "team", I am assuming that you are looking for ways to measure the Scrum Team (PO, SM, Dev Team), and not just the Development Team?   After all, only measuring one of the three Scrum roles doesn't really give you a complete picture of how well Scrum is being practiced.

In your mind, what may be some ways to measure PO and SM performance?

I concur with both Ian's and Tim's replies.  Story points are essentially an estimation tool. Their predictive nature helps the Scrum team and specifically the Dev team to understand the specificity of the efforts required in the particular sprint. As mentioned by both Ian and Timothy, assessing the performance of the team based on the story point is a no-no since it creates a sense of fear or a barrier towards story-points and the team may start to indulge or may be inclined towards gaming the story point system. 

We often forget that Scrum is not just product management or a project management framework. It is, in fact, one of the most sophisticated quality management frameworks that majorly relies on human collaboration and potential. 

In this particular case, I suggest a further logical breakdown of the story which still adheres to the delivery of a quality increment.

I suggest the following measurement criteria for measuring the Scrum Team's performance.

1. Reaction Evaluation - measuring the reaction time and costs for issues that are handled in the sprint.
2. Learning Evaluation - evaluating whether new technology, methodology or work process was incorporated in the sprint.
3. Behaviour Evaluation - evaluating whether there are notable supportive or disruptive behaviors in the sprint. Noting them and addressing them during the sprint retrospective. 
4. Results Evaluation – effect of increment delivery on the business for each sprint. 

I admit these criteria are quite big to address but I have had success with them.

Thanks  

I feel I'm missing something here:

Coming back to my question, what would it be your approach with a user story that goes across 2 sprints?

Would it make sense to just have the story progressing in 2 sprints? Or should I split it - even though I could not close the first one after one sprint?

The point I'm getting stuck on is your question "or should I split it?" I guess I don't understand your role/function, as I don't understand why it is apparently up to you to split a story or not. Can you elaborate on your role/function in your organization and what what accountabilities and responsibilities that puts on you?

Coming back to my question, what would it be your approach with a user story that goes across 2 sprints?

A different perspective on this question and trying an @Ian technique. Does your Definition of Done include anything about the increment being shown to the stakeholders?

I second @Bouke's question about your role and ask what role(s) are involved in refinement of stories based on the Scrum Guide? Why is it up to you as an individual?

an engineer has to travel to Japan to do a demo.

Is this a demo or the showing of completed work that occurs in the Sprint Review? If this is considered the Sprint Review how will the rest of the Scrum Team participate in order to learn from the feedback of the stakeholders and adapt the Product Backlog accordingly?

About the measuring of the team, I think everyone above has given you great advice. I especially like @Timothy's statement about the entire Scrum Team.  The Product Owner, Scrum Master and Development Team are responsible for the value that is being delivered not just the Development Team.  If the Development Team is not delivering value could it be because the Product Owner is not managing the Product Backlog to ensure that the Development Team is working on the correct value?