Documentation for GreenHopper 6.2.x. Documentation for earlier versions of GreenHopper is [available too].

計画スプリントや、現在進行中のアクティブなスプリントから課題を削除することができます。課題をアクティブなスプリント から削除すると、そのスプリントのバーンダウンチャート上に「範囲変更」イベントとして表示されます。

(info) 注意:

  • 本ページは スクラムボードにのみ適用されます。

  • You will need to have the 'Edit Issue' permission in the project to which the issue belongs.
  • If you are moving the issue above or below other issues, you will need to have the 'Schedule Issue' permission in the project to which the issue belongs.

To remove an issue from a sprint,

  1. JIRAにログインします。

  2. 上部ナビゲーションバーで Agile リンクの下矢印をクリックし、表示されるドロップダウンメニューから目的のボードを選択します。

  3. ボードが表示されます。
  4. Click either Plan or Work.
  5. Right-click the issue and select Remove from Sprint (see screenshot below).
    (info) Note that you cannot remove a sub-task from a sprint, as sub-tasks always belong to the same sprint as their parent.

Screenshot: removing an issue from an active sprint (in Work mode)

 


関連ページ

 

 

 

 

25 Comments

  1. nicolas frank

    Jun 04, 2012

    Now we need to be able to select more than one item and being able to remove it from the spring (as currently you can remove only one item at a time)...

  2. Anonymous

    Jun 04, 2012

    Anonymous; a workaround is closing the sprint, and starting a new one.

    nicolas frank: removing issues from a sprint should be a last resort; im glad the Rapid Board does not support this option, and hope that Atlassian will NOT support this in a near future.  

    1. nicolas frank

      Jun 22, 2012

      The trouble is that you have no place for "technical" mistakes. If I move the wrong stories in, I need to be able to remove them. Same with adding, I should be able to add a story and make it counted as initially there (count in the team commitment) if the story was just forgotten in JIRA : We use a physical kanban, so usually we have some delay with the JIRA representation (and sometimes some miskates)... still, the commitment is what the team decided, not what the tool decide for us ! When I see comments telling the tool shouldn't let you revert actions, I have the feeling that people are trying to fix internal process management issues with the tool, not really to efficient way...

      1. Nicholas Muldoon [Atlassian]

        Jun 22, 2012

        Hello,

        It is possible to add a story to an in progress sprint. It is also possible to remove issues from an in progress sprint. Both actions will result in scope change as your commitment is set when you start the sprint - and obviously you can change the commitment by adding or removing stories although that will be seen as scope change rather than from the start date of the sprint.

        Thanks,
        Nicholas 

    2. Janos Biro

      Nov 22, 2012

      yes, i also think Atlassian should decide how world works... e.g. people should not do mistakes and start a Sprint with too many tasks accidentaly... that should impossible... oh... is it not?

  3. Anonymous

    Sept 05, 2012

    Is there any way to add an issue to a sprint from the issue itself? Our product owner is accustomed to this behavior, and we are adding many clicks to have her go back to the planning board and find the issue that she was just looking it solely for the purpose of pulling it into the sprint. 

    1. Rosie Jameson [Atlassian]

      Sept 10, 2012

      You may like to vote/watch/comment on GHS-5407 - Getting issue details... STATUS

      1. Anonymous

        Jan 23, 2013

        For the Classic board, we are using the ‘Fix Version field’ when adding an issue and that will add/remove a particular issue to/from a sprint. We are highly using it for Bug issue type. But Scrum board doesn’t map this field any longer. This is one of the reasons (and there are few) why we are not moving from Classic to Scrum

  4. Anonymous

    Sept 18, 2012

    What is the permission associated with Removing an Issue from active sprint.  I assumed it would be tied to the Scheduling permission, but it's not.  It seems that anyone can remove?

  5. Anonymous

    Oct 18, 2012

    When I remove an issue from an active Sprint, can I configure it to go to the Backlog instead of the next Sprint?

    1. Anonymous

      Nov 19, 2012

      I have a similar but slightly different issue where when I remove tasks from a sprint, they disappear from my backlog all together.  I can find the issue by going to the Issues menu and searching for it there but i need to be able to drag the task in to a new sprint.  Help!

  6. Anonymous

    Oct 19, 2012

    Moving tasks in bulk between sprints was straightforward in the Classic planning board and is an helpful tool to manage scope changes during a sprint.  The new boards now require two actions per task to accomplish the same, a time sink.

  7. Anil Pillai

    Oct 30, 2012

    I have finished a sprint, and need to remove some of the tasks that are not completed. The on-demand version does not provide me that option.

    Specifically it does not provide the option "Remove from Sprint".  Is that a limitation of the on-demand version? Please help!

     

    Cheers

     

    1. Anil Pillai

      Oct 30, 2012

      Figured. It cant be done for sub-tasks!

  8. Anonymous

    Nov 05, 2012

    I have a concern with not being able to move sub-tasks from an active Sprint to a later Sprint.  When we start a Sprint, especially the first Sprint, we set productivity targets by adding tasks and sub-tasks to the Sprint.  However, as in any project, we may not always achieve our targets, which means that tasks/Sub-tasks will need to move to the next Sprint.  If 3 out of 5 sub-tasks were completed, I should be able to move the remaining 2 sub-tasks to the next Sprint.  Why is this not supported? Or is the work around to create a new story and add the remaining sub-tasks to it?  This should be much more flexible. 

     

    Thanks,

    1. Rosie Jameson [Atlassian]

      Nov 20, 2012

      When you end a sprint, any issues that are not complete will be automatically returned to the backlog (or to the next planned sprint, if you have one).

  9. Anonymous

    Nov 29, 2012

    The fact that I can drag and drop inside a sprint, from one unstarted sprint to another, from one unstarted to start sprint, but not out of a started sprint is extraordinarily frustrating. Right now for each issue I want to move, I am forced into a baffling 5-click process. JIRA seems to follow a pattern of design decisions that favor a strict workflow ideology over basic concerns over user experience and functionality. Atlassian should penalize incorrect workflows passively, by allowing me to do things but give me a note/alert afterwards ("Hey, doing that screws up reporting, next time try organizing your sprints better") not actively hinder basic functionality like drag-and-drop.

    1. Nicholas Muldoon [Atlassian]

      Nov 30, 2012

      Hello,

      Thanks for the feedback.

      To be honest, I'm not sure this is a tool problem so much as it is a process. The ideal behaviour is that the team commits to deliver an amount of work in a given sprint, and at the end of the sprint they deliver that. Ideally there would be no scope change in the form of issues added or removed during a sprint.

      Over time, usually 3 - 6 sprints for a new team in my experience, the team will arrive at a reasonably accurate measure of the amount of work they can complete in a sprint.

      Thanks,
      Nicholas Muldoon
      @GreenHopperTeam 

      1. Anonymous

        Dec 03, 2012

        It's pretty unrealistic to assume that new issues will not be added to a sprint as it goes on.  Given that new issues are added, what can then be achieved within the sprint changes, and obviously you must then move other issues out of the sprint.

      2. John Fenger

        Feb 27, 2013

        "To be honest, I'm not sure this is a tool problem so much as it is a process"  these are the word's i dreaded hearing from Atlassian, an this thinking counts for 90% of my teams complaints with the new GreenHopper.   I certainly hope this attitude doesn't define what JIRA is becoming.   Because Ideal and reality rarely meet its important to understand that many who use your products have a wind range of "ideal" development concepts.  You should be able to drag something out of a sprint, blocking this functionality to force people into someone else concept of ideal is unbelievably frustrating.  Please reconsider allowing this functionality. 

        John

    2. Anonymous

      Dec 03, 2012

      I concur. 

    3. Tom Kotecki

      Mar 05, 2013

      Hi Anonymous,

      Thanks for your feedback. Nicholas Muldoon is right here in that this is not an ideal behaviour and while it can happen, it should be a relatively rare occurrence. 

      Having said that, you can in fact remove an issue from a running sprint by using the right-click context menu in the plan mode and selecting "Remove from Sprint". 

      Hope this helps

      Tom Kotecki

      Product Manager, GreenHopper

  10. Shaun Stewart

    Mar 01, 2013

    I agree with the concerns expressed above.  The support for stories that in general will take longer than an iteration is poor.  It is easy to add subtasks and scope to an active sprint but no way to decrease it short of deleting subtasks.  Based on your comments Nicholas, I am beginning to think that Greenhopper is just not a good process model for the work my company is trying to do. 

    No matter how well you write a Story, when new scope and priorities arise during a sprint (which has never not happened during 18 months on my project), it results in the need to decrease scope elsewhere.  This is not supported by Greenhopper and thus significantly degrades the usefulness of the tool in my opinion.

  11. Shaun Stewart

    Mar 01, 2013

    When I re-parent a subtask from an active sprint to a Story in the backlog, why is the iteration scope not decreased?  This is a undesired behavior in my opinion because the Remaining Time Estimate in the Burndown Chart Report is no longer equal to the sum of the Remaining Hours in the Iteration.

    If the Remain Time Estimate does not equal the time remaining on the iteration, how is that not a bug?

     

  12. Dan Burzynski

    Jul 05, 2013

    Is there any way to trigger an event based on something being removed from a sprint. It's the sort of thing that Reporters like to know about! Or is there a way using JQL to identify things that have been removed from a sprint? Sadly, sprints do end with issues still open. As an organisation we'd like to be able to track these. I'm aware that the sprint report that's produced has a list of Issues Not Completed which is handy, but not easy to aggregate if you're looking back over a years worth of data. (sad)



Log a request with our support team.



Raise an issue for our developers.



See answers from the community.



Tweet, blog and update our documentation.

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.