How to handle unplanned items in JIRA/Greenhopper

I have setup Jira and Greenhopper and set up an initial sprint. I have mostly done scrum during my years via a whiteboard and face-to-face communication. I wonder how I should handle unplanned items using greenhopper? I don't just want to add a New Card and have it screw up the statistics. Would be nice to be able to get a figure of the ammount of unplanned work when th开发者_如何学运维e sprint is done. My initial guess was to add a New Card on the Task Board and tag it as an unplanned. But I don't seem to find any unplanned tag for a Card.

---

I've been using Greenhopper for about 1 1/2 years. It works pretty well and is invaluable to our team but isn't a substitute for post-its on the well for the daily stand-up. Over the 1.5 years, we've ended up collecting a lot of tasks, bugs, and other items in Jira that aren't immediate backlog items. Managing them is the most difficult in Greenhopper. These are the Unscheduled items.

I have these versions set up in Greenhopper:

Unscheduled: this is a holding pen for a few hundred items that we may or may not ever get around to. Some are ideas, some are bugs that we can't fix at the moment.

Unscrubbed bugs: as we find new bugs that aren't related to the current sprint's work, they go in here. Every week or so, we go through them and place them in one of the other versions.

Short Term Roadmap: stuff we'll get to soon but not in this or the next sprint.

Sprint Planning: this is the backlog we work from during planning. It's the higher priority items.

v2.3 - Sprint 2 (or whatever version/sprint we are currently working): This is the sprint backlog.

During the current sprint and before our sprint planning session, I organize the backlog and place the high priority items in Sprint Planning so we will get to them next. After the meeting, we place the items we sign up todo into the v2.3 - Sprint 2 and them manage it on a daily basis.

---

I think when you say 'unplanned items' you are referring to critical 'hot fix' tasks that need to be done ASAP. In my group we use a split team. We have one team that commits to the sprint. The Core Team. They are the only resource we calculate on to determine the amount of work we can do in a sprint. Another, much smaller team called the Firefighter Team is set aside to work on unplanned, critical items that, for example, might be needed in the next release.

We track these side-by-side. The Core Team is NEVER permitted to work on a hotfix item. However, the Firefighter Team is permitted to lend their skills as 'servants' to the Core Team if they do not have any critical items at the moment. Our split on one project is typically 4Core/2Firefighter. We rotate the Firefighter members each sprint, taking care not to remove someone from the next sprint that is in the middle of a big project spanning multiple sprints. So far so good. The only issue I have right now is tracking what amounts to parallel sprints in a meaningful way. I'll tackle that when it becomes a real issue.

---

See my feature request to Atlassian and Vote for it.

"As a Product Owner, I want new PBIs quarantined from the Backlog until I rank them"

https://jira.atlassian.com/i#browse/GHS-11139