How to use Remaining Estimate as the Per-Sprint Original Estimate?

[Jack White]

For the last four years, my team has used story points as the organisational metric for our sprints. So, we create a new task for the start of a sprint and we add both the story points and an original estimate.

Quite often a task will remain incomplete at the end of the sprint, because that is just life. Perhaps it took longer than you expected, or perhaps its completion relied upon someone else - to review the work, for example.

There is a problem here with the use of story points as a sprint metric - they do not actually reflect the amount of work that's gone into the task, even if they match up to some degree with your original time estimate.

I got the go-ahead to try out time-based sprints, but I cannot use remaining estimate as the sprint metric (estimation method) - it is not available in the board settings - only the original estimate or the story points.

I understand that you need an immutable metric against which to measure sprint performance, but this needs to be the remaining estimate at the start of the sprint, because if you have tasks inherited from a past sprint, that remaining estimate is the original estimate for that sprint.

It would be false if you were to move the remaining estimate into the original estimate, because these figures then are reflective of the actual effort put into the task. This was the whole problem with the story points - we were adjusting the story points at the start of the sprint, breaking the link between story points and the total task effort.

So:

How can I use the remaining estimate at the start of the sprint as the estimation method? This seems to be me to be the only sensible choice.

[Marc -Devoteam-]

Hi @Jack White 

This can't be done.

If you can't complete or finish a task in a sprint, you have the choice to move incomplete issues to the next sprint or split the issue and adjust the effort.

But in real life issues not finished will ge transferred to the next sprint and the Story Points or Original Estimate is not changed, as this was decided by the Team.

This is the learning curve, do we need to split work within refinement, that the task or story is to big, in the standup raise impediments on work tat is being blocked.

It is in my opinion also wrong when a team is working scrum to start measuring "real" effort (work time).

It should be on what value the team is delivering.

When scrumming is should not be around effort being but in but on the output the team delivers and the values that provides.

[Jack White]

Hi @Marc -Devoteam-

How would you measure output or value in this case?

What is the purpose of making estimates, either in time or story points, if this metric is treated simply as either 1 or 0 in the final analysis? The whole point of using Jira is to be able to track the work being done, not simply whether or not it was done.

Whether or not a task is finished within a sprint really has no correlation with whether or not it is too big. Sometimes people are just sick or have some emergency work, or a task relies upon a secondary person whose schedule does not match your own.

Failing to reach the end of a task by the end of the sprint is not a lack of delivery. You are still delivering real work.

You are right that issues not finished will be transferred to the next sprint and that story points or original estimate should not change, but it does not make any sense that work already completed should not impact the estimate for the new sprint. If I have 1hr left on an 8hr task, I can fit 7hrs extra in the new sprint, but if all the visual feedback in Jira says that this is an 8hr task rather than a 1hr task, it makes it really difficult to plan, which the purpose of the exercise.

[Jack White]

I cannot really believe that this is not possible. It kind of makes Jira a little bit useless. The actual organisational bit is missing.

[Marc -Devoteam-]

Hi @Jack White 

Story Points are for determining the effort/complexity the team thinks to achieve the work.

They are not meant to be used as an indicator for time.

Yes, it's not lack of delivery, but the work is not finished. So then you have a choice carry the item over or split the work.

But you have to look at the reason why the work din't finish, if it's on being blocked raise this the scrum master has to in consultation with a PO decide what to do.

If the work is just not finished was the work not refined enough?

All question to ask or details to look into, this should also be part of the retro of a sprint.

All tooling in relation to scrum behave this way, as it's part of the Scrum methodology.

Another question would be does the scrum WoW is the way to work for that team?