Sprint planning and carryover items

[Ben Brumm]

What's the ideal order of events for Sprint Planning and starting a sprint?

Currently my team does things in this order, at the end of Sprint 1 (for example):

1. Review any stories from Sprint 1 and move those to Sprint 2 if they are incomplete
2. Add stories to Sprint 2 from the backlog
3. Start Sprint 2 in Jira

However, this means that any "carry over" stories from Sprint 1 are shown as "Issues Removed from Sprint", which is not quite correct. They are stories that were incomplete and moved to the next sprint. Doing it this way means that the reports are incorrect (e.g. it shows we completed 100% of what we committed but that's not correct).

What's the alternative? Is it:

1. Start Sprint 2 in Jira, selecting "move incomplete stories from Sprint 1 to Sprint 2"
2. Add stories to Sprint 2 from the backlog

This can help us decide how much to add to the sprint from the backlog.

If we do this, then will there be an issue with the reports with having a lot of stories added after we click Start Sprint?

Or is it something like this?

1. Add stores to Sprint 2 from the backlog
2. Start Sprint 2 in Jira, selecting "move incomplete stories from Sprint 1 to Sprint 2"

This may avoid a scope issue in the reports, but we don't get a full picture of the sprint before clicking Start Sprint.

What's the best order of events?

[Kat Warner · Accepted solution]

We have a couple of hour gap between sprints. Our process looks a bit like:

1. Prepare for sprint close by closing all completed tickets. 
2. Review open tickets and determine if there are any you have worked on that should be split i.e. a 2 point ticket was partially completed  sprint 1. Update the ticket to 1 story point and close it in sprint 1. Create a new linked ticket in sprint 2 with the other 1 point for the work to be completed.
3. Do not move any tickets out of sprint 1 before it is closed as they were forecasted/committed to be done in sprint 1.
4. Close sprint 1, selecting "move incomplete stories from Sprint 1 to Sprint 2"
5. While you have no open sprints, review what is in Sprint 2. Move any tickets that fell into sprint 2 that you do not expect you will work on in sprint 2.
6. Add new tickets and/or tickets from the backlog to sprint 2 until you are happy with your forecasted work.
7. Open sprint 2.

Sprint 2 is visible in the backlog view before the sprint is started.

[Ben Brumm]

Ah, so you can close Sprint 1, do some planning, and then open Sprint 2. That could work.

We would be avoiding step 2 above (splitting and updating estimates) as it's something to avoid. But the other steps could work for us:

1. Close Sprint 1 at start of Sprint Planning, moving stories to either backlog or Sprint 2

2. Add stories to Sprint 2 from backlog

3. Start Sprint 2

This seems like it could address both of our issues.

[Nic Brough -Adaptavist-]

Yes, it will!  That's actually what the software was designed to do, although I don't think it is obvious that that is the case!

[Sam Prince]

Just to add to this - while a sprint is active you can edit its start date/time to be slightly later in case a few stories were added just after you started the sprint. That will fix your stats e.g. your burndown chart. If the sprint has finished I think it is harder/impossible to fix the start time retrospectively.