Capture burned (story) points for a partially complete task moved to next sprint

Question

If a sprint starts and a story has an estimation of e.g. 8 and at the end of the sprint the story for some reason has not completed, if I move it to the next sprint with the story points updated e.g. 3 for the next sprint, those 5 story points "burned" so far are not really captured in JIRA in the reports.
Is there some alternative approach so that all the "burned" story points are accounted for even for stories not finished in the sprint?

Answer 1

Why does it matter that those points aren't captured in the Jira reports?

Let's assume that you are using "burned" or completed points for velocity. Since the story isn't complete, you would "earn" 0 points for it. Your velocity for the Sprint would be the sum of the points associated with stories that you did complete over the course of the Sprint. You would then use your velocity (last Sprint's velocity or a rolling average over the past few Sprints, usually) to plan the next Sprint.

Let's now assume that you reestimate any unfinished work at the end of the Sprint and you reestimated this story at 3. If you were to assume no changes in capacity, your remaining capacity would be your past velocity minus the 3 points from the unfinished story and you can use this to sanity check the Sprint Goal and other work brought into the Sprint.

At no point do the 5 uncaptured points come into play.

Answer 2

A key aspect of Scrum is to focus on work that is done and not work in progress.

When we measure the story points achieved in a sprint, we measure them for the stories that reached our definition of done. That gives us a good indication of our capacity to get work done in each sprint.

Instead of trying to measure the contribution to a sprint of partially completed work I would recommend you focus on reducing the work that is carried over.

Some things that will help you with this are:

• Breaking large stories down (it is typically easier to complete smaller stories within a sprint)
• Putting less in to sprints (use your velocity to calculate the team's true capacity to get work done)

Answer 3

TL;DR

Unfinished work is simply "not done." Scrum is about delivering potentially-shippable increments of value at a relatively stable cadence, not measuring productivity or ersatz productivity-proxies like "effort expended." Each iteration, either the Sprint Goal was met or it wasn't. It doesn't matter how much effort was expended in the process; if that matters to someone, then you have a cultural issue to address within the team or organization, not a framework problem.

Techniques for Applying Effort-Tracking

Is there some alternative approach so that all the "burned" story points are accounted for even for stories not finished in the sprint?

There are any number of techniques, many of which have been around since the inception of Taylorism. When talking about user stories, the most common technique is called "consumed story points" in order to differentiate the effort expended from the original estimation. Other techniques for tracking effort variance from the original estimate can be found in tools like JIRA, and some tools like Pivotal Tracker treat "feature velocity" differently than other types of work. If all you want is an answer to your original question, you can stop reading here and just use this as a starting point for additional research.

Root Cause Analysis

So, there are certainly ways to track effort expended on unfinished work. However, this is an X/Y problem where you are trying to find a technique to provide a solution you've already decided on rather than uncovering or addressing the root cause. Y is the technique that you've assumed a priori will address the symptoms of your problem, while X itself goes unresolved. In this specific case, it seems likely that X is really an organizational or political problem where the team feels the need to justify deltas from an original estimate.

This is usually caused by one or more of the following process issues:

1. The 100% utilization fallacy, which is rooted in the notion that outcomes stem from how much effort is expended or how busy everyone on the team is.
2. Fiat management targets, where "productivity" is an externally-set goal rather than a realistic estimate provided by the actual task performers.
3. Conflating velocity, which is really a normalized capacity-planning and agile release scheduling tool, with individual or team productivity.
4. Confusing Scrum's framework for creating a predictable delivery cadence of incremental objectives (e.g. meeting the Sprint Goal more often than not) through the use of time boxing and just-in-time planning with "doing all the things" or with value delivery.
5. A company culture that requires teams or individuals to justify estimates as if they were promised a binding, money-back guarantee instead of an educated guess based on the information and resources available during Sprint Planning.

In other words, the perception that all effort expended must be tracked is fundamentally a CYA solution for a toxic company culture that tries to "hold people accountable" through proxy metrics like effort expended rather than hiring talented and self-motivated people, empowering them to self-organize, or trusting them to provide realistic estimates based on the skills, resources, and experience of the people actually doing the work.

This is basic Theory X management, and your search for a way to account for the team's efforts rather than establishing a predictable, outcome-based delivery cadence is a well-known agile anti-pattern. It basically boils down to the fact that leadership doesn't trust the team to deliver accurate or reliable estimates, and the team doesn't trust management not to punish them in some way when unrealistic estimates are forced on the team or unforeseen circumstances impact the current Sprint Goal.

Re-Establish Trust and Communications Through Collaborative Processes

What I described above is not at all uncommon in companies that are Agile in Name Only℠. The only viable solution is to ensure that both leadership and the team work together to re-establish trust, often through more frequent communication and improved process transparency. Everyone in the organization must agree to abide by the same framework and working agreements, regardless of what framework the organization actually uses. If the leadership team won't play by the same rules as the Scrum Team, then they are breaking the process and will get to keep both halves.