Incomplete stories and calculating velocity of partially completed work

Velocity, an optional metric in Scrum, is the average amount of Product Backlog turned into a "Done" Increment during a Sprint? Is you Increment "Done", meaning it is in a potentially shipable and releasable state? If not, your velocity is ZERO.

Thanks Chris for the reply. However, the idea is to use scrum for business/operational tasks etc etc so shipable doesn't fit here. And if we take only when it is done the velocity is calculated then it will give wrong indication in metrics

F.ex I have a story on 3 points and at the end of the sprint for some reasons I couldn't able to complete the story however I am partially completed (like say 2 points amount of work is completed). In this case, if I move the story to next sprint and complete the story then the next sprint velocity will be 3 (however actually it should be one) and previous sprint velocity for the story is 0 (however it should be 2). So in this case how we less administratively calculate the velocity of completed activities.

Hope you can understand my problem statement.

When I complete the sprint either I can move the story to next sprint or close the story in current sprint and open new story in next sprint.

Why doesn’t the team just re-estimate the story on the Product Backlog to reflect the work that is believed to remain?

However, the idea is to use scrum for business/operational tasks etc etc so shipable doesn't fit here. 

Releasing to production whether it is software, hardware, a service or whatever = shipping:)

 I fell for this trap too in the beginning. Besides the comments and questions quoted by my respected peers above, going into such a level of detailing and estimating is turning towards exact calculations and takes away the entire purpose of estimating. These kind of discussions lead away from creation of value and lead to satisfying metrics. Velocity is just a "tool", input for pulling in work during the Sprint Planning and maybe during the Sprint Retrospective. That's it.

Satheshkumar, you may have an incorrect understanding of story points.

Story points are to be used solely for planning purposes only.   They are not intended to be used as a proxy for team productivity, as they can be easily gamed.   They should never be used by anyone either inside or outside of the Development Team to assign credit or partial credit for items not completed.

Based on known velocity and upcoming capacity, a Development Team can assess how many 'points' it can comfortably forecast for the upcoming sprint.

At the end of each sprint, the story points for all completed items (meeting DoD) are tallied to provide another data point for the velocity calculation.

In your example, where a 3-pt item was not completed by the end of the sprint, that item should be re-estimated (according to effort and complexity remaining), and placed back into the Product Backlog so that it can be eligible to be brought in to a future sprint.   A Development Team should not get "credit" for work not finished, or waste any time/effort trying to assess what % of Story Points were completed.

if we take only when it is done the velocity is calculated then it will give wrong indication in metrics

What do you want to learn from the metric?

The answer to this is likely to affect what would cause a 'wrong indication'.

Developers are already worked partially on the story so the efforts spent on the previous sprint is lost if we move the story to next sprint

What is the purpose in counting effort spent?

If it's about reliable forecasting of what can be done in a sprint, perhaps it's unhelpful to count efforts that don't result in a done increment within that sprint.

If it's about measuring what the team can achieve within a sprint, perhaps it's better to focus on meaningful outcomes, such as the value delivered, rather than an arbitrary calculation of how much work was done.

I am in the same situation. I have many stories which are either in progress or open but havent been completed in the current sprint. If I put these stories back to the backlog and re-estimate it, will it not give an incorrect picture about the way estimations are done. Also for the sprint that closed, it was part of the committed story points. I am unable to get to a sprint velocity due to such stories rolling over.

Any help is appreciated. 

Why are the stories rolling over needed to be accounted from the previous sprint? The main goal is to provide a shippable or valueable increment, not account the points sprint by sprint, those are only a guide for the team to know they are delivering more in a given sprint on a given circumstances or events.

If your team delivered 100 story points from sprint 1 and delivered 90 story points from sprint 2, it does not mean your team sucks or is not improving, those story points are only estimates.

I'm going to play off of @Sherwin Soriano's response. 

• Sprint 1 = 18 stories - 180 points in completed stories - nothing deployed to production, nothing to show stakeholders to gain feedback
• Sprint 2 = 10 stories - 80 points in completed stories, 20 points in incomplete stories - nothing deployed to production but valuable feedback gained from showing working increment to stakeholders
• Sprint 3 = 8 stories - 100 points in completed stories (20 points that came from incomplete stories in previous sprint) - increment deployed to production and valuable feedback gained from showing working increment to stakeholders

Which of these are the most successful?  I say all 3 of them were because the team learned from all.  I am implying that the team learned from Sprint 1 and adjusted their expectations downward for Sprint 2. 

Quite trying to make story points more meaningful than they are.  They are estimation tools and nothing else. They aren't meant to be rewarded or even celebrated.  The delivery of useful working software, the learning from past activities, the improvement over time are things to be rewarded and celebrated. 

I'm going to leave this here for future.   This is a blog post by Rod Jefferies, the man said to have invented Story Points.  It is a good read and in my opinion pertinent to this topic. 

https://ronjeffries.com/articles/019-01ff/story-points/Index.html

Interesting article...

Kindly clarify on below

1) During the sprint while team working on user story, as per agile manifest, is it ok to modify or add more requirements in the acceptance criteria ? for example if the team says 2 hours it would take to work on the new requirement. What is the best practice ?

2) If the team story point the user story - 5 and while working on the user story if the team feels it should have been user story point - 8, in this situation should the team continue working on the user story, complete and demo? what the team should do ?

3) After user story demo, if the PO is not satisfied because demo is not per acceptance critiera, because team finds the one of requirement in the acceptance critieria is not clear, so in this situation should the team rework on the user story and redemo again to PO ? or Create a new user story, refine and pull into the sprint based on the priority ?

4) After the user demo to PO, User story demo is successful, but if PO identifies requirement gaps, so should the PO create a new user story, refine and prioritize the user story ?

Thank you.

1) During the sprint while team working on user story, as per agile manifest, is it ok to modify or add more requirements in the acceptance criteria ? 

What do you think can happen if you don't update it ? what do infer from one of the Agile principle that says - 

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

2) If the team story point the user story - 5 and while working on the user story if the team feels it should have been user story point - 8, in this situation should the team continue working on the user story, complete and demo? what the team should do ?

As per the Scrum Guide - 

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

Is this user story part of your Goal ? Is this doable in one sprint ? can the work associated with this story be split into small user stories ? What do you think is more important to identify the more work needed to complete the Story or re estimate ? Guide says - 

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

If estimation is used for forecast and should be improved with experience. Then would it be beneficial to update these estimations throughout the Sprint or take these learning for the next iteration & improve ?

3) After user story demo, if the PO is not satisfied because demo is not per acceptance critiera, because team finds the one of requirement in the acceptance critieria is not clear, so in this situation should the team rework on the user story and redemo again to PO ? or Create a new user story, refine and pull into the sprint based on the priority ?

I am assuming Demo is not Sprint Review but just a demo for internal team and PO. How often does your PO and team collaborates ? I would ask if acceptance criteria was not clear then why this was not addressed to PO while developing the Story. 

4) After the user demo to PO, User story demo is successful, but if PO identifies requirement gaps, so should the PO create a new user story, refine and prioritize the user story ?

Again assuming its an internal team demo and not Sprint Review with users and stakeholders. What does your PO think about the increment , can it be delivered without these new requirements ? Or are these new requirements critical for delivering an increment ? I would again stress on the team collaboration with PO.