0

I would like to continue working on an item in the next Sprint, but if I move my card into the backlog for that Sprint it will remove it from the current Sprint. That isn't what I want.

I would like to continue working on this item until the end of the Sprint, and have it counted in the current Sprint. Is there a way of doing this?

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
heretoinfinity
  • 101
  • 2
  • 1
    Why? Either it's in the current Sprint or it's not. What are you actually trying to solve for by treating something as future work while still actively working on it? – Todd A. Jacobs Oct 05 '23 at 02:03
  • It won't be complete in this current sprint and something else that is more important came up. – heretoinfinity Oct 05 '23 at 20:52
  • Then you should be working on the "more important thing" and not the current thing. So, it should be removed from the current Sprint. Q.E.D. – Todd A. Jacobs Oct 06 '23 at 21:25
  • @ToddA.Jacobs, actually no. Life is not as simple as that. I have a set time to do something in the current sprint for a different stakeholder. I don't want to get the item where I would have to then redo a number of tasks sort of like loading things into RAM again. I need to leave it at a state where I can pick it up again. – heretoinfinity Oct 08 '23 at 23:50
  • Then you aren't following either the Scrum framework or core agile principles; you're prioritizing your own workflow over the defined framework, which is an anti-pattern all its own. As Bob Lewis repeatedly points out, "To optimize the whole you have to sub-optimize the parts." – Todd A. Jacobs Oct 09 '23 at 00:09
  • Maybe a better way to say it is that you're trying to make JIRA say "Something is out of scope for this Sprint" while still working on it in the current Sprint anyway. Maybe there's a way to do that, although I don't think so; just put in a comment that something else is taking a higher priority, and leave it in the Sprint to create transparency around the fact that some planned work wasn't done. Unless you're trying to CYA, that's likely the right thing to do anyway. If the interruption isn't reflected as drag on your current Sprint then the JIRA report will be inaccurate anyway. – Todd A. Jacobs Oct 10 '23 at 23:07

3 Answers3

2

When you end the sprint, Jira asks you what to do with unclosed issues. You can move them to the next sprint, or put them back to the backlog. FYI: https://support.atlassian.com/jira-software-cloud/docs/complete-a-sprint/

Nezih TINAS
  • 486
  • 3
  • 9
  • I am not the owner though. It is the tech lead that closes out the sprint. Does this mean that I have to go talk to him separately and be around when he closes the sprint? – heretoinfinity Oct 05 '23 at 20:53
  • Yeah. You can put a process in place about how to act when and how to end a spring in Jira. – Nezih TINAS Oct 09 '23 at 10:32
2

TL;DR

If you're following Scrum and not just doing some sort of "cowboy agile" you are not allowed to carry work from Sprint to Sprint without moving unfinished work back to the Product Backlog for re-prioritization and re-planning. This is part of what makes Scrum adaptable to changing circumstances and requirements that evolve over time.

Furthermore, work that can't be completed within a single Sprint shouldn't be accepted during Sprint Planning in the first place, and if it can be removed without endangering the Sprint Goal or the goal can be renegotiated with the Product Owner then do those things. Items unrelated to the current Sprint Goal or that won't meet the Definition of Done cannot be considered part of an Increment, and shouldn't be allowed to sidetrack the Developers from the current Sprint Goal.

Most of the analysis section is about why you're having what appears to be an X/Y problem. If you just want to jump to the recommended solutions, they are enumerated in the final section at the bottom.

Analysis and Recommendations

Problem Analysis

I would like to continue working on an item in the next Sprint, but if I move my card into the backlog for that Sprint it will remove it from the current Sprint. That isn't what I want.

What you are trying to do is an anti-pattern. Work should never automatically roll over, nor should work for future Sprints be scheduled prior to the end of the current Sprint. The 2020 Scrum Guide™ requires unfinished work to be returned to the Product Backlog for possible reconsideration in the future:

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Furthermore, either the item is required for the current singular Sprint Goal or it is not.

The Sprint Goal is the single objective for the Sprint...The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

Based on your description of the problem, you are likely missing one or more of the required Scrum artifacts:

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:

  • For the Product Backlog it is the Product Goal.
  • For the Sprint Backlog it is the Sprint Goal.
  • For the Increment it is the Definition of Done.

That often drives anti-patterns such as Sprint Backlog items that don't meet INVEST criteria and can't fit within a single Sprint, or working on things that aren't part of the current Sprint Plan.

Deeper Analysis

Either the work is no longer on the critical path to the current Sprint Goal, or it is but can't meet the Definition of Done within the time box defined by the Sprint. You have to look at various parts of the Scrum Guide, but it is quite clear that work that can't be completed within a single Sprint should not be included in the Sprint Plan. When the guide says:

Selecting how much can be completed within a Sprint may be challenging. (2020 Scrum Guide™ § Sprint Planning)

it's implicitly saying that work should be decomposed to fit within a single Sprint before being selected for the Sprint Backlog. More importantly, incomplete work should never be planned or included within a defined Increment:

Work cannot be considered part of an Increment unless it meets the Definition of Done. (2020 Scrum Guide™. Scrum Artifacts, Increment, para. 3)

That doesn't mean teams don't make mistakes or can't modify scope. The Scrum Guide provides a means for taking things off the critical path, which includes putting unfinished work back on the Product Backlog.

If the work turns out to be different than [the Development Team] expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

If the Sprint Goal can't be met even after renegotiation, then the framework provides another escape hatch:

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

Since there can only be one Sprint Goal and one Product Goal at a time, e.g.:

The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

a drastic change to either would require a return to Sprint Planning. Again, this is by design: either the change is important enough to be made a visible cost to the project and should trigger re-planning, or it doesn't in which case there is no reason not to reconsider the item's value to the current Sprint.

In either case, work essential to the Sprint Goal must be completed within the current Sprint to be worked on. Doing anything else is "not Scrum." If the team or the organization insists on doing something that is prohibited by the Scrum framework then go right ahead, but you're not permitted to call whatever you're doing instead "Scrum." A very common cause of people saying Scrum doesn't work! is that they don't implement the framework as intended, and then place the blame on Scrum itself rather than an improper application of its theory, principles, and required events.

Recommendations

Since it seems like you're asking how to do a thing in JIRA, but what you're really asking is how to do something non-Scrum in JIRA. Here are some key recommendations that should help, even though they don't tell you how to do what you want (and shouldn't do) in JIRA.

  1. Ensure the Scrum Team has a clearly defined Product Goal, Sprint Goal, and Definition of Done. Without them, you can't fix the underlying problem.
  2. Don't select work for a Sprint that won't be completable within a single Sprint. Decompose as necessary, following INVEST criteria when possible. A formal Definition of Ready may help too, but understand that mistakes happen.
  3. Don't select work that isn't relevant to the current Product or Sprint Goals. A lack of focus and coherence means you're treating Sprint Planning as a tasking system for a feature factory rather than a product development process.
  4. Don't be afraid to change course when needed. A core agile principle is to embrace change, even late in the process. Scrum provides many ways to do this within its framework.
  5. Determine if the work is essential to your current Sprint Goal. If not, remove it from the Sprint Backlog or renegotiate the Sprint Goal and associated Increments with the Product Owner.
  6. Do not schedule work for future Sprints ahead of time. Sprint Planning is a dynamic process, and is based on where you are right now and where you're currently trying to go. Since priorities, goals, processes, and tools can change, Scrum uses just-in-time and just-enough planning to meet continuously evolving requirements. That means you should leave planning future work until the last responsible moment, and that's usually during the Backlog Refinement event or Sprint Planning.
  7. Don't let your tools drive your process. A common mistake with any process, but especially when talking about agility, is designing your process around a set of tools rather than selecting tools that support your process. In this case, it sounds like JIRA is doing the right thing as defined by Scrum; if it weren't, then you should fix or replace the tool rather than let the internals of the tool (and JIRA is intrinsically a ticketing tool rather than a team-based Scrum backlog management tool) drive you towards implementing a substandard process.
  8. Remember that "The goal of a Sprint is to complete the Sprint Goal." The inability to complete non-essential tasks or to maximize utilization are also anti-patterns, and CodeGnome's Scrum Tautology℠ is pretty clear that you should be focusing on that rather than on falling prey to the 100% utilization fallacy.
  9. Don't assign work to people. Story points or tickets completed aren't "victory points" or a useful way to hold people accountable within an agile framework. As a ticketing system, JIRA tends to drive a lot of non-agile behavior, but the whole Scrum Team (especially the Developers) collectively owns the commitment to deliver a successful Sprint Goal. Nobody gets brownie points for doing anything other than delivering working Increments that align with the Sprint and Product Goals, and that meet the Definition of Done. Always remember that this can happen whether or not all tickets are completed prior to the end of the Sprint!
  10. Don't assign future tasks or chores to specific Sprints. During Sprint Planning, the Developers select work off the Product Backlog that aligns with the current Product Goal and creates a unified Sprint Goal. While that sometimes means adding tasks and chores to the current Sprint Backlog based on what needs to be done to meet the Sprint Goal, assigning future work to specific Sprints actually makes the framework less adaptable. Don't do that!
  11. If this isn't a one-time problem, make sure to address it within your Sprint Retrospective. Every process has occasional hiccups, but Scrum is meant to drive continuous process improvement. If you are routinely facing this challenge, then you need to inspect-and-adapt your process as a team. Unless the problem is more urgent than meeting the Sprint Goal, the Sprint Retrospective is usually the right place to discuss the challenges and alternative approaches.

In short, JIRA is (for once) doing the right thing by saying something is either currently in-scope or it's not. Everything else stems from either a political problem within your organization or a misapplication of the Scrum framework. If it's a political problem where you're trying to avoid blame or earn "productivity points" then focus on fixing the culture problem. If it's a misapplication of the framework, then work together as a team to continuously improve the process until it runs more smoothly.

See Also

Here are some various links to related posts about "effort variance" and "consumed story points" that seem at least tangentially relevant to your question. There are doubtless others as well.

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
  • I read the TLDR. The work wasn't completed because of something unforeseen during planning. There was a bug that was introduced by an external team and investigating workarounds took longer. Now although the idea was to continue with tackling this problem in the following sprint the product manager, not the engineering lead, mentioned that there's something a client needs and that would take a sprint. P.S. there are no retros in our team unfortunately so it is "wild west" agile. Trying to change it won't bear much fruit so I haven't pursued that further. – heretoinfinity Oct 10 '23 at 13:44
  • @heretoinfinity While I empathize, I think the original question you asked is about making JIRA generate an artificially mangled report where either work-in-progress or drag on velocity are swept under the rug. If you want to do what you're doing, then let the work show as unfinished in the current Sprint and add it to a subsequent Sprint. That's correct behavior regardless of what you do with the work item in the current Sprint. – Todd A. Jacobs Oct 10 '23 at 23:18
1

First of all, you should consider the reasons why you want your task to be counted in the Sprint where it doesn't belong. Is there a good reason for that? If this is simply a matter of having a nice report for the previous Sprint, then it's definitely not in line with Scrum principles. Scrum is an empirical process that promotes openness about the work and its challenges, as well as the courage to do the right things.

Perhaps the item is too big and should be sliced. Maybe the item couldn't be finished on time, or a dependent task was not completed on time or as expected. All of these options should be considered seriously.

However, I don't see any strict restrictions in Scrum regarding moving work between Sprints. I would strongly advise against doing it, but there are sometimes valid reasons for doing so. And, let's be honest, sometimes people make mistakes, and that doesn't necessarily mean they should be fired. But the work still needs to be done, and improvements should also be made. If it happens, it's better to identify the problem as soon as possible and improve whatever needs to be improved. The first step in this process is to admit that the work item was not finished as planned and needs to be moved now. So, the Sprint Report won't be perfect, and someone may need to be held accountable. This is what openness is about. On the other hand, moving the work item to the next Sprint but accounting for it in the previous Sprint is not fair and seems to be an attempt to hide the problem.

Lastly, Jira allows for multiple Sprints to be active at the same time. I would argue that this is mainly applicable to Scrum at scale, where there are multiple Scrum teams working on the same product. However, it can also be applied to a single team. Nevertheless, I would advise against using this feature for a single team without a very good reason. This may be a topic for a completely different discussion.

Valentyn Hal
  • 11
  • 2