How to handle stories that were not completed

First of all strive to come to the state where stories will be completed. But in case stories are not completed, you have two options.

1. Split

2. Carry forward

I had a discussion with Agile coaches on the same point.

They offered the following distinctions:  If you SPLIT a story, the team will not get credit for the points (since they didn't deliver) but they will get credit for the hours worked.  If you MOVE a story, then the team will not get credit for the points NOR will they get credit for the hours.  IN ANY CASE, YOU SHOULD NOT CHANGE THE POINTS ON THE STORY.  If you change the points when you move and/or split, the team will not get credit for the points in the first iteration AND when the do get credit it will be for less points since the point value was changed.

Splitting of stories also highlights the fact that the team has not been able to deliver what they have committed (in terms of a story) and thus, there is some scope of improvement (planning, solution, requirements accuracy or implementation). This would strive the team to focus on the issue at hand and thus, would help the team evolve from agile as well as delivery perspective.

1) The team did not have enough time to implement it correctly and it's not usuable at all.

     In that case, I think we should just put the story in the next sprint (if possible) and re-estimate its points. We don't add any points to the total for the current sprint as the story is not complete at all

2) The team almost finished the story, but it's missing something for it to be accepted (small bug, or logo/image not completed yet by the designer, who's part of the team) . 

     In that case, do we count any of the story points in the current sprint's total number of achived points?

I think your reasoning in the first case seems fair and sensible.

What though do you believe is so critically different, in the second case, to justify the “counting” of any points for that story in the Sprint? Why do you think it might now be right to do so, in this instance?

IN ANY CASE, YOU SHOULD NOT CHANGE THE POINTS ON THE STORY.  If you change the points when you move and/or split, the team will not get credit for the points in the first iteration AND when the do get credit it will be for less points since the point value was changed.

Per the Scrum guide (found in the sprint cancellation section, but applicable to any incomplete SB items):

"All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog."

The motivation should not be around getting credit for work done.   Items are either complete or incomplete.   It is a poor practice to encourage teams to claim credit for partial work.   This isn't about them, but about what value the business is receiving from them each sprint.

Splitting an item (i.e. - completing an item but moving its cosmetic defect as a separate item for a subsequent sprint) can result in closing the item and creating/estimating a separate item.   Moving an item intact should not result in any points credited to the team.   How does it help a team to base their velocity on incomplete items?   How much waste is involved in having teams evaluate what portion of an incomplete item is actually complete, and how that should translate into completed points vs incomplete points?   

Keep in mind also that story points (or other relative estimation methods) are for planning purposes only.   It does not help the team (and creates waste around conversion/translation) to keep estimates intact when moved out of a sprint instead of re-estimating the remaining work.

IN ANY CASE, YOU SHOULD NOT CHANGE THE POINTS ON THE STORY.  If you change the points when you move and/or split, the team will not get credit for the points in the first iteration AND when the do get credit it will be for less points since the point value was changed.

"We do not deliver points. We deliver value" - The author of this sentence is a developer from my former team. Do you see the point? Story Points are useless, if you don't have the Increment. 

Hello David, 

Acceptance criteria plays very important role in estimating and completing the User Story. If Development Team has achieved acceptance criteria of that particular user story. They can go ahead and close it. BUT even if a small thing is yet be finished then user story will be considered incomplete. 

1. As you explained that team could not complete the user story then in that case, Story should put back to Product Backlog. Scrum Team should re-evaluate the importance of user story. If user story needs to be completed to achieve sprint goal then it should be carried forward to upcoming sprint. 

2. As i mentioned above, if user story does not achieve acceptance criteria then it will not be considered as complete.Either it can be put back to product backlog or can be moved to upcoming sprint. Depends upon business requirement and importance of that user story. 

I hope, i was able to answer your question. 

Thank you all for your answers.

To answer Ian's question

What though do you believe is so critically different, in the second case, to justify the “counting” of any points for that story in the Sprint? Why do you think it might now be right to do so, in this instance?

In the second case, the uncomplete work in the story is not a showstopper.  Most of the 'heavy work' has been done by the developpers, but the designer failed to deliver a logo or background image in due time. The feature is still usable as such, e.g. "As a public user I can log in the website using the 'log in' button", but that button is missing an icon next to the 'Log in' label.

My main motivation for counting points for uncompleted stories  is that I'm afraid of the impact of 'almost completed' stories on velocity and other indicators. 

For instance, take the case where  the team works on a story with a high number of points, almost completes it, but does not get any point for it. The story will then be completed in the next sprint, but will not worth many points since there was not much work left to do..

As pointed by Timothy, points are for planning only; however in this scenario (no points), this will lower the velocity (on average) and might lead to the impression that the project will take longer to complete than it will

My main motivation for counting points for uncompleted stories  is that I'm afraid of the impact of 'almost completed' stories on velocity and other indicators. 

For instance, take the case where  the team works on a story with a high number of points, almost completes it, but does not get any point for it. The story will then be completed in the next sprint, but will not worth many points since there was not much work left to do..

As pointed by Timothy, points are for planning only; however in this scenario (no points), 

My advice is to rethink the idea of a team "getting" points and of them having "worth". Neither of these are in line with the principle that they ought to be for planning only.

this will lower the velocity (on average) and might lead to the impression that the project will take longer to complete than it will

If the partially completed work is being re-estimated on the Product Backlog, then any such impression would be false, because less work would be thought to remain.

I think you should not focus this the problem in terms on how to deal with uncompleted Sprint backlog items in terms on splitting them to give credit to the development team. In the Scrum Guide it's clear how to deal with that as Timothy pointed

"All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog."

I'd suggest to tackle this issue during the Sprint Retrospective with the following Questions in mind:

• Where the Backlog Items correctly splitted?
  • During refinement and Sprint planning?
  • Did the development team notice before the end of the sprint that those items could have been splitted better?
• Does the Definition of Done need to be adjusted?
  • Do you need design to get items Done?

I understand that your main concern is how to deal with the actual situation so, follow the Scrum Guide and encourage the team to find a way to avoid uncompleted tasks in the future.

In the second case, the uncomplete work in the story is not a showstopper.  Most of the 'heavy work' has been done by the developpers, but the designer failed to deliver a logo or background image in due time. The feature is still usable as such

A few thoughts here:

• Was the logo part of the original acceptance criteria of the item?   If not, then was it missed in refinement (missed requirement)?   If yes, then it would be the PO's decision whether to accept the item as delivered (usable), or reject it because it was incomplete
• Who is the "designer" here?   Is this a specialist within the Development Team, or an external dependency?   If external, what is the history with delivery within the sprint from this dependency?   Should the Development Team even accepted the item if they were unsure whether the logo could be delivered by this external dependency in time?
• If the designer was a specialist within the Development Team, then you should note that in Scrum, it is critical to emphasize Team Ownership of all sprint items.   Work does not belong to a single individual, so it is fundamentally incorrect to state that the "designer" didn't deliver the logo.   The Team didn't deliver the logo
• Velocity is a guiding metric for teams to use in planning, and should be based on completed work only.   It seems incredibly wasteful to me to expand this practice to include portions of incomplete items

@Ian

If the partially completed work is being re-estimated on the Product Backlog, then any such impression would be false, because less work would be thought to remain.

I don't agree with that, but maybe my logic is flawed. Take  a 1000 point backlog when project starts. During sprint 1, the team agrees on doing 126 points, so there are 874 points left in the backlog. At the end of this sprint, say that:

• the team gets 80 points for fully completed stories
• two 13 point stories are not completed, so they are  re-estimated at 1 point each (it was not missing much, just an icon or there is a small bug) and put back into the backlog, which has now a total estimate of 876
• Team velocity is 80

With that velocity, a rough estimate is 876/80 = 10.9, so 11 sprints left at this pace. But if the team was granted partial points for their work on the 2 uncompleted stories, say 10 points for each, then velocity would be 100. This would lead to an estimate of 876/100 = 8.7, or 9 sprints left to complete the items currently in the backlog.

If the designer was a specialist within the Development Team, then you should note that in Scrum, it is critical to emphasize Team Ownership of all sprint items.   Work does not belong to a single individual, so it is fundamentally incorrect to state that the "designer" didn't deliver the logo.   The Team didn't deliver the logo

The designer is indeed a specialist in the team, and no, the idea was not to blame him.

Velocity is a guiding metric for teams to use in planning, and should be based on completed work only.   It seems incredibly wasteful to me to expand this practice to include portions of incomplete items

Same as above my response to Ian. I do understand that it is for planning, but  I feel that it'd lead to skewed measurements (see axample above)

@ana

• Where the Backlog Items correctly splitted?

   

  • During refinement and Sprint planning?
  • Did the development team notice before the end of the sprint that those items could have been splitted better?
• Does the Definition of Done need to be adjusted?
  • Do you need design to get items Done?

Maybe we are using the wrong approach, but we don't want to have stories that are too short (they take between 1h and 3 days of work). In the example I'm using, it did not feel right to split a story between design and functionality, since the design part was limited (e.g. creating an icon). For later sprints, we'll decided to split the designer's stories from the other stories, so that he can work on it in advance.

And modifying the Definition of Done to say "it works, but design does not need to be finished" does not feel right either

David,

I don't agree with that, but maybe my logic is flawed. Take  a 1000 point backlog when project starts. During sprint 1, the team agrees on doing 126 points, so there are 874 points left in the backlog. At the end of this sprint, say that:

• the team gets 80 points for fully completed stories
• two 13 point stories are not completed, so they are  re-estimated at 1 point each (it was not missing much, just an icon or there is a small bug) and put back into the backlog, which has now a total estimate of 876
• Team velocity is 80

With that velocity, a rough estimate is 876/80 = 10.9, so 11 sprints left at this pace. But if the team was granted partial points for their work on the 2 uncompleted stories, say 10 points for each, then velocity would be 100. This would lead to an estimate of 876/100 = 8.7, or 9 sprints left to complete the items currently in the backlog.

Yes, you would have two different forecasts based on whether you counted incomplete work or not.   But how accurate would such a forecast be if it tried to consider incomplete efforts?   

And how much wasteful effort would teams/PO's have to use to calculate what the partial points would be for incomplete items?   

And what is the incentive to the team to actually reach Done at the end of the sprint, if they're encouraged to just carry items over from sprint to sprint?

And how does the concept of unfinished items help the PO to forecast completion dates?

If I may make a suggestion, this may help:

Use story points to help the Dev Team / PO plan a sprint.   Once the sprint starts, throw the points away.   Don't even look at them anymore.   



The only time sprint backlog items should ever care about their story point value again is if it is either complete (to include in velocity calculations), or if it is moved out of the sprint or left incomplete at the end of the sprint (re-estimate remaining effort for future planning purposes and place in backlog).

You'll thank me later.   ;-)

Take  a 1000 point backlog when project starts. During sprint 1, the team agrees on doing 126 points, so there are 874 points left in the backlog.

Strictly speaking, there are still 1000 points left in the backlog, regardless of any agreement, because none of the work has yet been done. The Product Backlog should always show the amount of work which is currently understood to remain.

At the end of this sprint, say that:

• the team gets 80 points for fully completed stories
• two 13 point stories are not completed, so they are  re-estimated at 1 point each (it was not missing much, just an icon or there is a small bug) and put back into the backlog, which has now a total estimate of 876
• Team velocity is 80

In the situation you describe, the team appear to have planned in 80+13+13=106 points.

By the end of the Sprint, fully completed stories account for just 80 points of work, so the team's velocity is 80. That leaves 1000-80=920 points in the Product Backlog. Re-estimating the two 13 point stories down to 1 point each means that each is reduced by 13-1=12 points. The backlog therefore shrinks by a further 2x12=24 points. 920-24=896 points remain.

A calculation based on velocity would suggest 896/80=11.2 Sprints remaining (i.e. 12 Sprints needed). However, the 24 points (which constitute the work partially completed) are accounted for as work which no longer remains to be done. A suitable projective technique, such as a product burndown chart, would show a reduction in the size of the Product Backlog of 80+24=104 points. The number of Sprints remaining may then be projected, using the chart, to be 896/104=8.62, or 9 Sprints.

The key thing is to properly account for the work, and to use appropriate projective techniques that tell you as much as possible from the data you've got.

I think one point that everyone is missing is that you don't use actual velocity of the previous sprint to do forward planning. You use an average or an average range of past velocity.  So given that, does it really matter if a story is moved out of a sprint and into the next as is?  The points given to a story is an indicator of the complexity of completing the entire story.  So if in this case, they did the entire story except adding a single non-functional visual element.  Is that really so bad?

Honestly, here are the 2 alternatives I'd suggest to the team:

1. Complete the story in the current sprint and do the 20 minutes of work needed to add the icon in the next sprint without a story.  It would take longer to do all of the story management than it would to just do the work and be done.
2. Move the entire story as is with it's current points into the next sprint and then do the 20 minutes of work.  Take all of the points credits in the next sprint.  Then when start looking forward, the average velocity is still going to be about the same.

Sometimes we try to make things harder than they need to be.  Agile is about transparency, inspect, adapt.  Scrum isn't about "getting points".  It is about delivering value in increments.  In this case, you delivered significant value with a minor cosmetic problem.  Quit trying to make it harder than it really should be.  Discuss why the logo was late in the retro, learn from that.  Teach the team the value of delivering value and not being punished for missing a logo.  And for heaven's sake, deliver the value and move along. 

Thank you all for your responses.

@Daniel

I think one point that everyone is missing is that you don't use actual velocity of the previous sprint to do forward planning. You use an average or an average range of past velocity. 

Yes that is true, but if the problem will remain if this scenario occurs repeatedly (of course, this would mean that we have a problem somewhere)

However, i'm not sure if just doing the extra work without proper tracking is scrum-like

@Ian,

A calculation based on velocity would suggest 896/80=11.2 Sprints remaining (i.e. 12 Sprints needed). However, the 24 points (which constitute the work partially completed) are accounted for as work which no longer remains to be done. A suitable projective technique, such as a product burndown chart, would show a reduction in the size of the Product Backlog of 80+24=104 points. The number of Sprints remaining may then be projected, using the chart, to be 896/104=8.62, or 9 Sprints.

The key thing is to properly account for the work, and to use appropriate projective techniques that tell you as much as possible from the data you've got

Exactly, 2 different estimates. And in 2nd one, you do count 'partial points', so this impacts velocity (even if you don't call it that, and maybe that's my problem). How do I know which estimate I should use? For me, it should be the 2nd one

@Timothy

And how does the concept of unfinished items help the PO to forecast completion dates?

For me the team has produced value in 'almost complete' tasks, so this has a direct impact on forecasting (as example above). 

And in 2nd one, you do count 'partial points', so this impacts velocity (even if you don't call it that, and maybe that's my problem)

No, there aren't any "partial points". The amount of work which is estimated to remain is reduced, and work which is Done is measured separately. That's it.

The way language is used in Scrum is important, because it is valuable to transparency.

Yes that is true, but if the problem will remain if this scenario occurs repeatedly (of course, this would mean that we have a problem somewhere)

That is true.  You do have a problem somewhere, but Retrospectives are for discussing that type of issue.  I'm not saying to ignore the fact that stories are incomplete. I'm saying that putting too much effort into splitting stories or the exercise of reevaluating the points is not the solution to that problem. It actually hides the problem and makes it seem like it is normal because "scrum has a way to handle it".  I think the problem needs to be discussed and addressed in much more debt. Get to the root of why stories are not being complete and fix those problems instead of trying to find a way to obfuscate the issue. 

Very good contributions here, kudos everyone.

Re "With that velocity, a rough estimate is 876/80 = 10.9, so 11 sprints left at this pace. But if the team was granted partial points for their work on the 2 uncompleted stories, say 10 points for each, then velocity would be 100. This would lead to an estimate of 876/100 = 8.7, or 9 sprints left to complete the items currently in the backlog."

I'd like to add that, for all the transaprency you, the whole team, the managers and the organization "itself" are genuinely throwing in, though on paper (for Ian had explained the reality and pointed out the proper burndown use) it may look as there is a discrepancy and therefore incorrect data (11 vs 9 sprints), in reality it's always good to have a cautious approach, especially in software projects (everyone knows that).

Not to mention likely future changes to the backlog (based on stakeholder input/market changes) that may increase (most always) or decrease the required effort. Throw in technical debt > refactoring, code defects, and you're in for a treat.

And, even if the business expects completion, based on "current" effort of 876 points, in 11 sprints, there would be no complaints if completion takes 9 sprints.

As many had said before me, don't even bother about points - they're supposed to show the relative effort thought to be needed to create a product/feature that ultimately brings value for the business. So focus should be on value delivered per increment, and as a whole (per all increments), not number of points completed per increment.

While working on the user stories, we create the tasks for the user stories.

At the end of the Sprint, we only move the left over tasks to the next sprints and not the entire user story.

We don't change the story point. The credit will go the the sprint in which the user story is resolved meeting the acceptance criteria.

Thanks

It seems to me we are getting confused between delivering value and estimating the effort involved in delivering that value.

Story points are used to comparatively estimate, based on past work, how much effort it will take to deliver a story. With this knowledge the development team can get a feel for what effort is required to deliver the value in an upcoming sprint and to aid in sprint planning.

If an 8 point story is not 'done' then zero value is delivered. The credit should be the team delivering the value not burning points.

not completing a story should be an exception and as others have said the team should discuss the story/sprint in the retro - inspect, learn and adapt with a view to being a bit wiser for the next time.

Formally the story should then move to the backlog to be reviewed again by the PO. If the story is picked up again then the story should be re-estimated. It may be that there is more effort required to deliver the story than was ever known, maybe it needs to be split into different stories now that we understand more, conversely it may be that the work left to do is now less as some of the work has been done. If the story is not re-estimated the effort to deliver the value of the story is not clear for the PO or the team.

It's at this point everyone gets hung up on the lost velocity points - well, remember velocity is an average and small changes like this will not make much of an impact to the velocity. Remember, the velocity is there to help the team deliver value not a metric for managing performance per se.

I don't think anyone covered another aspect of Story not being able to complete. 

In my experience QA always run one to two sprint behind on some story and that due to that reason bigger story are not consider as completed even though the functionality was implemented 100%. The way we handled this situation is give a story point by excluding QA efforts and split the story into two one for Development and one for QA in the next sprint. 

I am happy to hear what approve other take to resolve this situation. 

[1] If the sprint duration is currently 2 weeks then you can try for 3 or 4 weeks sprint.

[2] initially the team may need to experience the domain, organization specific processes, interface applications and standards, new technology, new frameworks. So better to plan accordingly for initial sprints.

[3] So planning is the key

Thanks.

Put it back in the backlog for re-prioritization of the PO. Discuss in the retrospective and then adapt to the situation so that it won't happen again.

I am a bit late, but...

I think it is very important to prioritise Sprint goal over small details.

The main question is - is that small part of the work which is not done restricting the team from reaching the goal? If it is restricting from reaching the goal - then put the whole story back to backlog, re-estimate, re-prioritise. If it is not restricting from reaching the goal - then change your acceptance criteria accordingly and consider the work done as expected value is still there. This decision should be done before Sprint Review from my point of view.

From my perspective, if icon on the login button is preventing product from getting the value, then there is definitely something wrong with team's agility.

1 or 2, either case re-refine/ plan the story based on the need of work required according to teams suggestion in sprint planning.

In sprint retrospective - work with team to find out how to overcome situation now, prevent such situations in future.

Either case story won't be a part of sprint review. If its a small things which is not completed, and can be completed in consequent sprint, with the teams consent, move the story into consequent next sprint. 

How to handle stories that were not completed depends on the situation. for clarification You want to know the story's complexity. As much as story points are essential, encouraging teams to claim credit for partial work will be a poor agile practice. The end goal of the sprint is about value. any uncompleted stories should be returned to the backlog for re-estimate and prioritization

The idea of putting incomplete stories back into the backlog and re-estimating before the next Entry makes sense. But I have two questions.

1) This may affect the list of anchor stories negatively. For example, the team may not remember that a 13 point issue was incomplete in a sprint, put back into the backlog, and brought back re-estimated at 3. They may then use that as an example of a 3 point story in the anchor list.

2) This may skew the velocity. Let's say the team doesn't complete a 13 point story in a sprint and doesn't get any credit for it. They bring re-estimate and bring it back into the next sprint as 3 points, and complete it. 3 is what will be reflected on the velocity report instead of 13.

What am I missing?

First thing you are missing is that story points are the worst thing you can use to determine velocity.  They are educated guesses made at a point in time based upon the information they have at the time they make the guess.  Estimates are useful to a team to determine if they feel a set of items can be completed during the Sprint time box.  But once work begins, estimates are no longer useful. Velocity isn't how many estimated points you do, it is the amount of value you deliver. 

I have never used the practice of anchoring stories but from what I understand of it, the anchor story is only useful for a single Sprint because the goal is that story will be completed.  Each Sprint has a different anchor story identified and then the rest of the Sprint Backlog is formed around it.  But after that story is completed, it no longer has any kind of significance.  So I see no issue with re-estimating an incomplete anchor story if it was not finished in the Sprint. 

I suggest that you spend some time studying the Scrum Guide to learn more about the Sprint Goal and use that as a basis for your Sprints.  The Spring Goal is used to focus the work done during a Sprint on a specific goal that delivers value.  The Anchor Story concept, from my understanding, focuses more on having a consistent amount of story points. 

Thanks, Daniel. But I think you're making some assumptions about my level of knowledge, so let me clarify what I meant by anchor stories and how we use them. 

One of the teams I am working with is new to Scrum (or Scrum is new to them). Anyhow... they're just getting used to relative comparison and story points. To assist, we've put together a list of issues from the past that fall into extra small (1,2 points), small (3-5), medium (5-8), large (13,20), and extra-large categories. When faced with a new story that seems hard for them to understand the complexity of, it helps to look at the anchor list and see if there is anything that we can compare to. We update the list every once in a while. My concern (not a big one) was that we could accidentally put a former 13 point into the small category because it had been re-estimated.

In regards to "First thing you are missing is that story points are the worst thing you can use to determine velocity.  They are educated guesses made at a point in time based upon the information they have at the time they make the guess.  Estimates are useful to a team to determine if they feel a set of items can be completed during the Sprint time box.  But once work begins, estimates are no longer useful. Velocity isn't how many estimated points you do, it is the amount of value you deliver. " 

Velocity is an actual metric in Jira that helps the team to understand how much they usually manage to complete in a sprint. So it is a scale for quantifying the value delivered. This data along with many other factors help the team understand whether the sprint backlog is doable. So I am not sure why you call points "the worst thing". What else defines velocity? When you say "velocity amount of value you deliver" how do you quantify value?

Sorry, I did not mean to make it seem I was assuming you had any level of experience.  I was just providing my opinion based upon the little bit of text that was available.  Anyone that responds in this forum is only able to give their opinion because there is not a "right way" to do things that applies to everyone.  

My concern (not a big one) was that we could accidentally put a former 13 point into the small category because it had been re-estimated.

Do you have a concern that some of the stories on your list were over estimated and should be removed?  I understand what you were trying to do but honestly, I don't see how re-estimating a story that has been partially done to reflect the remaining work would be a problem for this.  Since you use Jira (based on your recent response) it would be easy enough to add a comment explaining it was changed.  The activity history for the ticket would already reflect the change.  You could also add a big bold "DO NOT ADD THIS TO THE ANCHOR LIST".  You could add a label that says "Do add to anchor list".  There are multiple ways to do this that could be filtered out in a search of completed items. I would not use this potential problem from preventing the team to accurately reflect the work that is still needed. 

Again, this is my opinion.  Velocity is a great measure.  However using Story Points as the basis of that metric is not a good idea.  There are many ways to measure velocity and I usually advocate for those.  For example, lead time or cycle time are more accurate in my experience.  They measure based upon actually delivery rather than guesses.  Since Story Points are guesses and do not reflect the actual work I do not advocate using them for anything but for the Developers to estimate if they feel it is possible to complete a body of work during a Sprint time box. You can use cycle time or lead time to determine how much work is actually completed and use those measurements to determine if the body of work selected for the Sprint Backlog is realistically possible to complete during the Sprint time box. 

There are many teams that can successfully build Sprint Backlogs without using estimates at all. Others use actual hour estimates instead of relative sizing.  Still others might use Value Points instead of Story Points.  There are MANY ways.  Jira has decided to use Story Points for their implementation. But they also provide other reports that can be used.  

...how do you quantify value?

This statement is from the Scrum Guide's section that describes the Increment. 

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

This statement comes from the same section but under the subheading of "Commitment: Definition of Done"

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

You can determine value based upon delivery of valuable increments. Instead of looking at how many Story Points you have "burned", look instead of how frequently you are able to successfully deliver valuable increments.  In the end, your stakeholders don't care that on average you are able to "burn" 38 points per Sprint.  They care that you are on average able to deliver them value every 1 to 2 weeks. 

This is my opinion based upon my experience.  Your opinions will reflect your experience.  I am not saying that you are doing things wrong because it is impossible for me to do so without experiencing the same thing you are. I am providing you my opinion and some alternative ideas because you asked for people to do so.  I wish you luck and would be interested in hearing how this works out for you.  After all, that can be something I can add to my knowledge base and allow me to learn something through your experiences. 

Velocity is an actual metric in Jira that helps the team to understand how much they usually manage to complete in a sprint.

Good, that could be useful.

So it is a scale for quantifying the value delivered. 

No it isn't. It seriously isn't. Velocity is the rate at which work is Done, and there is no reason to suppose that all Done work is equally valuable.

The conflation of the amount of work undertaken with the value obtained from it raises questions about product ownership. Do stakeholders even care about the value obtained Sprint by Sprint, and the ability to validate whatever is learned from it? Why has velocity become a proxy measure for value in the first place? Is there really just a schedule of work here, which Developers are plowing their way through, waterfall style?

1. For stories that aren't usable at all due to time constraints, it's a good practice to carry them over to the next sprint and re-estimate their points. However, you're correct not to count their points in the current sprint total.

2. When a story is almost complete but missing minor elements like a logo for professional services or has small bugs, it's typically considered incomplete for the current sprint. You can count the points achieved so far and create a new story to address the remaining issues or missing elements, adjusting the points accordingly. This keeps the sprint's metrics accurate while ensuring that all work is tracked and completed appropriately.

Per Scrum Guide " If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration."

When dealing with incomplete PBIs, I suggest looking at them from the perspective of the Definition of Done. It is possible that the User Story is partially complete and the elements, which are complete meet the definition of Done for the Increment and are valuable to the Stakeholders. In such a case, I suggest splitting the User Story. 

It is also possible that the User Story is partially complete and none of the work completed meets the Definition of Done for the Increment. As such the entire User Story needs to go back to the Backlog and the partially complete work needs to be removed from the Increment.