Automatically add new issues to the current sprint

[Rob Fagen]

My team has started planning sprints for the engineering productivity tools we work on, but we also have ad-hoc service work that I want to get folded into the sprints. I want to measure the cost of walkups on the "make the world a better place" work.

It would be helpful to have every issue that comes in through an issue collector automatically be added to this week's sprint. I looked at some other answers on this idea, one of which suggested a post-function, and I'm attempting to write that function using the scriptrunner plugin and groovy.

I'm stuck trying to get to the rapidview helper so I can quiz it for the most recent open sprint. I get a NPE on the getRapidViews call, so below I'm just returning rvHelper, which is null (unsurprisingly).

Any hints on what's wrong?

Thanks,

Rob

import com.atlassian.jira.ComponentManager
import com.atlassian.plugin.PluginAccessor
import com.atlassian.jira.bc.project.ProjectService
 
ComponentManager componentManager = ComponentManager.getInstance();
def jiraAuthenticationContext = componentManager.getJiraAuthenticationContext()
def user = jiraAuthenticationContext.getUser()
 
PluginAccessor pluginAccessor = componentManager.getPluginAccessor();
Class rvHelperClass = pluginAccessor.getClassLoader().findClass("com.atlassian.greenhopper.web.rapid.view.RapidViewHelper");
def rvHelper = componentManager.getOSGiComponentInstanceOfType(rvHelperClass.class);
return rvHelper
def rapidViews = rvHelper.getRapidViews(user)

[JamieA · Accepted solution]

Leaving aside all the good responses regard process, I wrote a tiny bit about how to use script runner with greenhopper here: https://jamieechlin.atlassian.net/wiki/display/GRV/Miscellaneous+Groovy+Scripts#MiscellaneousGroovyScripts-WorkingwithJIRAAgile(thepluginformerlyknownasGreenhopper)

Your code would work with getBean("rapidViewHelper") from my example.

[Kim Poulsen]

It sounds to me more like you want a Kanban-style agile setup with swimlanes and high/low markers for your team. (Sorry no code examples :-] )

If you want to control inflow, outflow, and perhaps how much of a certain kind of work is going on at any one time Kanban is your friend.

Do remember that Scrum is definitely not a golden bullet for all. Support teams have in my company never had luck with Scrum, but Kanban seems to work for them with their appropriate filters and swimlanes.

Scrum is for focused work towards a common goal where the unknown factors for getting there outweigh the known factors.

[J. Caldwell]

So...by default adding things to your sprint will throw everything off don't you think? Things you don't complete, get added to the top of the queue when you close the sprint? Shouldn't the better approach be to ranking and prioritizing these other kind of request and adding them to a start of a sprint?

If the problem is getting it into your view, you should be able to alter the root filter to include those items in your board.

[Rob Fagen]

J.,

Not to drill too much into the topic of "what is agile, anyway", but I suppose my objective is specifically, as you say, to "throw everything off".

My team (Software Delivery Services) is in charge of three things:

1. Building the tools and frameworks that help the product engineers produce more features, more safely and faster
2. Executing the tasks for building and delivering these features to production
3. Automating all of those tasks in #2 until they're self-service for the product engineers and their product leaders

So, if #2 is taking 100% of my team's time, my team is never getting anything done for #1 & #3. Nothing ever gets any better for the product engineers. The more my team can execute #1 & #3, the less time my team spends on #2, leaving more time for #1 & #3. Product engineers own their own destiny for development, building and deploying, interrupting my team less. Virtuous cycle.

I want to be able to track how much work my team is doing and understand the composition of planned strategic work, planned repetitive/scheduled work and unplanned work.

By planning a sprint with all the cool stuff we want to do, layering in the scheduled repetitive work and then adding all the ad hoc work during the week into that same bucket, I can track the unplanned inflow and outflow as well as being able to trend total capacity of the team (regardless of whether it was planned, scheduled or unplanned work).

Anyway, enough philosophy, how about some code examples? :)

Thanks,

Rob

[Kirsty McWilliam]

A use case for this is also if you've included Story Testing into your Definition of Done - any bugs that are raised through testing of the story must be fixed in order for the story to be Done, so you'd want these automatically added into your current sprint.