Changing estimation between sprints

Natalia Osiecka

The easiest way of this explaining the question will be by example.

Let's say we've got 4 columns: ToDo, WIP, Testing, Done.

Two scenarios:

In sprint1 we estimate story1 to be a 5-pointer. The story stays in WIP to the end of the sprint. Burndown chart shows 0/5 points done.
We start sprint2 with that story and we move it to Done. Burndown chart shows 5/5 points done.

Another scenario:

In sprint1 we estimate story1 to be a 5-pointer. We finish WIP and move it to Testing. Burndown chart shows 0/5 points done (I suspect?).

Now we're planning sprint2 and zero the story, so it's a zero pointer (because WIP part is finished). We start sprint2 with that story and we move it to Done. Burndown chart shows 0/0 or 5/5 points done?

The question is asked because I'm not sure if when I do it I'm missing those points completely and they never appear in my burndown charts or it's keeping them in memory. I heard it is a common practice and it adds those points to the completed points of burndown chart and velocity, but it's not completely logical for me and I want to be sure how it works.

Troy Spetz_46oct3

We use JIRA Server 7.10 version.

 

JIRA does not handle the 'carry-over' of incomplete work from one sprint to another. There is no native field which stores two DEV SP estimates: The original estimate and the estimate-to-complete (ETC).

On our team, if an issue is not finished (e.g. 5 DEV SPs) and is carried over to the next sprint, we re-estimate for the effort remaining (e.g. 2 DEV SPs).

As a result, 3 DEV SPs are 'lost'. The work was done (in previous sprint) but because the issue was not closed in the previous sprint, the team does not get credit for doing this work.

Not nice, but JIRA assumes all planned sprint work is completed in the same sprint.

 

As a workaround, you could consider:

1. Creating a custom metadata field which captures the the ETC SP budget. As only the native 'Story Points' field will work with JIRA charts and reports, this field would store the original SP budget estimate. Of course, this makes it much more difficult to determine how many SPs are left to be done in the current sprint (i.e. if it contains carried-over work).

2. If you have carry-over work from the previous sprint (while planning the next sprint), you could manually keep track of the original SP estimate versus the ETC SPs. This would look like you are overloading the sprint-being-planned's budget. At least this way, the team would not lose credit for work already completed.

 

Of course, the best solution is to ensure the team closes all work within in the sprint that it was estimated.

 

(Aside: We never manage to achieve more than 80-90% closure of the sprint-planned work because, to do so, the Developers would have to be doing nothing on the last day of the sprint -- while the Testers closed the remaining issues. In reality, we usually have to add a few high priority defects to the sprint -- to keep the Developers busy until the next Sprint planning session.)