Editing Sprint points of stories during sprint?

I teach my teams that they cannot change any estimates (user story points or timed tasks). It needs to be noted and discussed at the retrospective.They need to learn from their mistake, live with it for the sprint but make sure that they do their investigation much better next time.

A team should always update their estimates in order to accurately reflect the work that is believed to remain. Transparency is needed over this.

There's nothing to stop a team from keeping a history of estimates for retrospective purposes. Electronic tools may support this to a greater or lesser degree. I coach teams with physical boards to put a line through an estimate and simply write the amended one next to it.

Ian,

does your approach mean, that at the end of the sprint all completed stories should have 0 SP assigned?

In theory, yes. A scrum board should always tell the truth.

In practice team members should update estimates as often as the data will actually be needed. Typically, this means that the estimates of work remaining should be in an accurate state for the Daily Scrum and/or for when relevant metrics such as a task burndown are generated.

But Ian, then why estimate in the first place?
We may as well increase or decrease the points when we get to the tasks to get the latest info.. Also some days things may feel harder than on other days.

I think for my processes I'll go with the no-reestimation way unless there are really good reasons to reestimate mid-sprint (something happens that affects difficulty of all stories globally, or someone who would've made a story easy got sick and now it's very hard).. Maybe.

The purpose of burndown and points is to get things done and help motivation.. Probably reestimating will dilute the value of the process of estimation in the long run.

Thanks for the answers, looking forward to read more on this.

That's actually an interesting idea. I see some downsides, though. The distance between story points may be too great to indicate daily progress (reduces transparency). The other issue, I guess, would be creating too strong relation between Story Points and time.

It is probably why the task-level tracking is more popular way to indicate the remaining work. Especially if team follows the rule that tasks should be less-than-a-day of effort.

Has anyone used JIRA to do task-level tracking?

The only way I found to do that was by using sub-tasks and this doesn't work with burndown charts either.

The burndown chart is only useful if it's used as a daily information radiator - it's kind of useless if only reviewed at the end of the sprint, seeing a drop from "100 to 0" on the last day.

In agile, a story is only "done" when it's "done" according to DoD, so technically subtasks shouldn't reduce the burndown chart. The way it's implemented in JIRA makes sense - so...

Do you call JIRA stories epics and call JIRA stories as technical tasks and make them 1 point each or something?

What's your take on this?

Ian, Bartek, this is interesting conversation. So you estimate the story point for a particular story at the start and then track the remaining work in terms of hours or days. Is that correct? I understand story point helps you to determine velocity of your team, but do you actually revise your story points during the Sprint or the best is to keep it as it is but stick to revising the remaining work on daily basis. In that case what is your conclusion for the unfinished story in terms of its story point estimates?

A team should have transparency over the estimated total amount of work planned for the entire Sprint, and the estimated amount remaining at any given point. Both measures are subject to revision and ought to be kept up to date and accurate.

It's no more complicated than that. It doesn't matter whether the estimates are in story points, task hours, or something else entirely.

Right. So if lets say the team does the estimates in story points, will tell the remaining amoung of work for the whole sprint in terms of story point, but not for each story. Right?

They could do it that way, as long as they have an up-to-date view of the total work forecast in the Sprint and the total estimated work remaining. It may be easiest to estimate pieces of work individually first, but if a team prefers to estimate a body of work in aggregate then they are perfectly free to do so. Scrum makes no prescription about how they obtain such measures.

Perfect, cheers Ian