need help figuring out how to track tasks that we didn't complete in the sprint

I need some advice.
We just finished a sprint where 3 tasks for one story were not completed. We are going to complete them in our next sprint.

I am not sure the best way to manage this. I don't want to just move the tasks from one sprint to the next because my data won't be correct for the sprint they didn't finish in. I want to historically show that those weren't done and keep the burndown chart showing we didn't finish. However, I don't want random subtasks out there that will never show as being finished.

How do I handle this?

Hi M,

That is a difficult one ... it will depend on what is most important to you I guess.

I will start with what we do in this situation.

We have a 2 level hierarchy of versions.
o Release 1
oo Iteration 1
oo Iteration 2
oo Iteration 3

When we release Iteration 1
1- We copy the chart and publish it on our project wiki.
2- We release the iteration and we swap all the unresolved issues to the Release 1 to be rescheduled.

This answers our needs, but we have drawbacks from it.

You might consider the Clone option and playing with the estimates, again you will have drawbacks (Duplicate data ...)

I encourage you to post this on the JIRA user forum, I am sure that many people had the same need. There is a lot of subscribed users on it and the replies are relatively fast.

I think that like us your are looking for some velocity chart.
Like a burdown of Points and why not a burnup as well.
We are currently brainstorming on the next chart to implement.

Sorry that I couldn't give you a more constructive answer, I will ask around me and see the feedback I am getting.

Cheers,

thanks...I have posted to the Jira forums

Hi Megan,
As JC mentions, this is not an easy one.

In most Agile processes, there is no partial completion. A story is either done or not done.

When you release the iteration, you should move the story with its tasks up one level (release) or in the next iteration. Note that GreenHopper does that for you automatically.

The total story points for the version will be displayed in the planning board and will not include the points for the story that was not completed and this is exactly what you want. It would be great if GreenHopper would allow to graph watched fields. You would get velocity chart over time.
Stay Tuned!

The other chart that would help here is a burndown chart for a watched field (ie Story Points).

Finally we are looking at implementing a burnup chart. The x axis is time, the y axis is percentage. This is especially useful if you have a value field for your stories.

Cheers,
~François

I agree - there is no parital done. However, if I move the tasks to the next iteration, then the burndown will change and it will look like I completed work that I didn't. I want the burndown to show that I didn't finish all the work for that sprint so it is historically correct.

Hi M,

This is why we want to build a velocity chart. It will answer some of the things that the burdown chart can't answer today.

You have to remember that the burndown is dynamic. It has advantages and drawbacks.
Not keeping the historic will be in your case one of the drawbacks.

Cheers

jchuet wrote:

You have to remember that the burndown is dynamic. It has advantages and drawbacks.
Not keeping the historic will be in your case one of the drawbacks.

I'm trying to figure out how this works, also. It seems to me that, since the Sprint has a start and end date, the burndown should remain accurate.

The Stories and Tasks that were not completed in Sprint 1 and were added to Sprint 2. Unfortunately, the drag-and-drop feature in the Planning Board moves them rather than linking them to both Sprints.

As a workaround, I found that I can edit the Stories (JIRA issues) and Tasks (JIRA sub-tasks) to contain both Sprint labels. This is quite inconvenient, so it would be helpful to be about to do this on the Planning Board. I have not yet investigated if the resulting burndown for Sprint 1 remains correct even after the Tasks and Stories are completed in Sprint 2, i.e. that the ending date of Sprint 1 is observed in creating the burndown chart.

all the best,
George

Since Version 1.6 we now keep the snapshots of the Sprints.

If you release your version from the planning board and still have unresolved issues in your sprint GreenHopper will ask you if you wish to swap them in the next version ...

It will also show you the charts that will be saved as snapshots. GreenHopper will take a snapshot of your charts before swapping any issues so you have the accurate charts of your Sprint at the release date.

You will be able to review these charts from the Released chart viewer.

Cheers,

jchuet wrote:

If you release your version from the planning board and still have unresolved issues in your sprint GreenHopper will ask you if you wish to swap them in the next version ...

So if I "swap" them, will they be in both sprints?

No they won't.
They will be reassigned to => Release - Next Sprint

You are bringing up a very good point though. and the more I think about it and the more I like it. I will bring up that idea for sure (could be an option from the release action).

Thanks George that is a pretty neat idea.

Cheers,

jchuet wrote:

You will be able to review these charts from the Released chart viewer.

Where do I find the Released Chart Viewer?

Also, if the unfinished tasks are removed from the sprint, won't the figures for the Sprint that are shown on the right-hand side of the Planning Board be incorrect?

The Released chart viewer button is at the top of the right hand column in the planning board (Dark Grey header)

The column will still be correct, you don't see the released versions in that column and the release action refreshes all boxes.

Cheers,

jchuet wrote:

The Released chart viewer button is at the top of the right hand column in the planning board (Dark Grey header)

Thanks. I see that the teams I'm helping have not been "releasing" the sprints, for the most part. Is that the general recommendation for end of sprint?

jchuet wrote:

The column will still be correct, you don't see the released versions in that column and the release action refreshes all boxes.

Where can I find this information for previous sprints? If I'm going to use a tool that tracks the estimates, it would be useful to me to have the historical data so that I can look for things that are puzzling.

For releasing, yeah I do recommend it.

GreenHopper is more a tool that was implemented to help users to manage their ongoing versions.

We didn't focus on the historical data since GreenHopper is sitting on JIRA and JIRA does a very good reporting job.

But in future releases we might consider to support in a more GreenHopper way the historical data.

I hope that answers your concerns.

Cheers,