nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Sprint planning: Carry forward stories(issues)

Scott Thurston_22s9a2

When near the end of a sprint, i would like to be able to show some issues(stories) in the current sprint and in the backlog for the next sprint. This is to help in forecasting how much can be pulled into the next sprint. The Product Owner needs to know what issues will carry over and should be allotted for in the next sprints capacity.

Is there a way to have a story show in the current sprint and next sprint but still be the same story (same key) so that any updates in the current sprint are reflected in the upcoming sprint?

I would like to hear from others about how you manage the forecasting at the end of one sprint before the next sprint is made active. thanks to anyone that will share how you work.

Accepted answers

Warren_mz9b4z

Hi @Scott Thurston

From a Jira point of view, no you cannot do that. In the "Backlog" view, the current sprint is shown, so you cannot have the story shown twice in that view.

Generally, at the end of the sprint, there is a decision made for each unfinished story - does it go into the backlog because other stories have higher priority, or is it going into the next sprint. We usually do this in Jira by moving all stories to the next sprint initially, then deciding and moving some into the Backlog. You're then able to look at capacity and see how many new stories can come into the sprint.

All comments

Warren_mz9b4z

Hi @Scott Thurston

From a Jira point of view, no you cannot do that. In the "Backlog" view, the current sprint is shown, so you cannot have the story shown twice in that view.

Scott Thurston_22s9a2

Thanks for taking the time to answer my question. We do pretty much exactly what you are describing but I sure wish Jira (the tool) would help more with forecasting this process.

Yes, it works fine while in the Sprint closeout and Sprint planning session. However, I would like to be able to do some pre-work and forecasting a day or two before sprint end and have betting insights to what we will be able to accept in the next sprint. It would be very helpful with prioritization and communication with business partners.

Joseph Stamatiades

Sounds like the Sprint Retrospective is where these issues should be discussed based on Scrum framework.

You are not really suppose to forecast in advance because product owner has to have input into what is included in next sprint.

Jira will let you add backlog items to second sprint if they are not completed in current sprint.

Scott Thurston_22s9a2

Yes. All that is true and does work. We do that at sprint close out/sprint planning. Just wishing for the tool to help with that process a day or two prior to the sprint close out/sprint planning. We do it manually on paper or in our heads but it would be nice if the tool could make it easier and more visual. Just a quick way to color code issues that will most likely carryover would be helpful. One can dream :-).

Kevin Lawrence_8qs5qj

I feel like this is a common question and I disagree with the answer that "you shouldn't want to do this." The issue comes up when a story of 5 points is 90% done but needs a tiny bit more work in the next sprint. Usually we take that forward to the next sprint and finish it there. But the issue is in the sprint burndown (or epic, release burndowns) it shows that we did no work in the first sprint and over worked in the second sprint.

Scott Thurston_22s9a2

I hear you but all the agile training says don't take credit till it is fully done.

My issue is more around marking which stories will most likely carry over to the next sprint and how much of the work (or points) are actually going to be done in the next sprint. It would be such a BIG help if Jira provided a method to highlight or tag them and a way to have them forecasted in the next sprint when the PO and SM are trying to plan the next sprints capacity. It is like we need a dry-run space to plan the next sprint before it is ready to start - but that next sprint needs to include the carryover items for better planning.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

plan