Skip to main content
Sprint planning and forecasting in Jira using ScriptRunner
Share on socials
A person holds up a magnifying glass
Mo Backer
Mo Backer
23rd June, 2020
Cloud icon

Sprint planning and forecasting in Jira using ScriptRunner

Sprint planning and forecasting in Jira are absolutely essential for any team. You can get better using data.
Sprint planning and forecasting are absolutely essential for any team. You will inevitably commit to too much or too little in any given sprint, but you can get better at planning by using data. If you track a consistent set of meaningful metrics, you’ll know what you’ve achieved in previous sprints. That means you’ll know what you can reasonably expect to achieve in future sprints.
But getting this information can be difficult. We know it’s all there in Jira, the issue is getting visibility of it and storing it in an accessible way. Using ScriptRunner, we’ve come up with some solutions. First though, let’s take a look at how you might go about sprint planning and forecasting.

Data-driven sprint planning

Whether it’s sprint planning, tracking progress against your roadmap, or reporting, having a consistent set of sprint metrics is essential. These metrics will vary from organisation to organisation, but there are two universal themes that every team will need to think about.

1. Understanding capacity

There’s one question you need to get to the bottom of here: how much can we deliver in a sprint? This will depend on some tangible aspects, such as your team size and the skills mix within it. There are also some intangible elements that will of course impact productivity, such as your team’s motivation levels. The key here is to go beyond the headlines, dig into the details and uncover the metrics that are meaningful. Because knowing capacity is the first step towards realistic planning.

2. Prioritising efforts

The other side of the equation is knowing what we want to deliver. We all have a backlog that we’d love to work through, but it takes time. Each sprint planning session needs to have ruthless focus on prioritising work so that the ambition matches the team’s available capacity; and, of course, the team objectives.
Taking the themes above, we’ve listed some of the sprint metrics that you may want to track. We’ve broken these down into the readily available metrics, and the ones you’ll want to get hold of for intelligent forecasting.

High-level metrics

  • Total number of epics - are we focussing on enough or too many high level themes?
  • Total number of story points - are we taking on enough or too much work?

Detailed metrics

  • Status breakdown of story points in the current, outgoing sprint - what are we likely to carry over from previous sprints?
  • Component breakdown of story points e.g. frontend vs. backend - are we balancing our work appropriately?
  • Number of story points assigned to each developer by component - are we being reasonable in our allocation or could we optimise allocation?
  • Number of spikes - are we taking on too much undefined work that risks impacting the progress of other story points?

Intelligent forecasting

Forecasting is inherently wrong. But getting a good sprint forecast isn’t as hard as it might seem. It needs a breakdown of tasks and a historic data trend that can be extrapolated. There will be one-off events that you’ll have to take into account, such as a team member being away on holiday. But if you have a data trend for what is typically achieved, your extrapolated forecast won’t be far from reality.
Once your data-driven sprint planning process is underway, you’ll soon have a large enough historic dataset to start analysing. For example, after 5 sprints you might realise that there’s a correlation between the number of spikes in a sprint and the number of story points being carried over into the next sprint. It may be that a high number of spikes results in more leftover story points due to spikes containing more work than anticipated. You’ll then know that minimising the number of spikes will help meet sprint goals.
This kind of simple analysis and forecasting can go a long way to improving the entire sprint process, helping to give your team a clear and realistic goal to work towards.

Using ScriptRunner to automate sprint planning and forecasting

ScriptRunner is used by many organisations to help with their sprint planning and forecasting process. There are 4 main steps before you can start your data-driven planning and forecasting. ScriptRunner enables you to do the first three.
  1. Extracting the data you need
  2. Automating the extraction process
  3. Storing the data for each sprint in an accessible way
  4. Data analysis

Step 1: Extracting the data

The metrics we spoke about above can be extracted using ScriptRunner’s script console. The snippet of code below is an example of how you might start going about this. It will find the total number of story points in a particular sprint, as well as their breakdown by assignee, issue type, status and component.

Get story points

1def issuesInSprint = get("""/rest/agile/1.0/sprint/${sprintId}/issue?
3   .header('Content-Type', 'application/json')
4   .asObject(Map)
5   .body
6   .issues
7assert getIssuesInSprint.status == 200 

Step 2: Automating the data extraction process

ScriptRunner lets you automate this data extraction in a way that suits your use case. Using the script listener feature, you can fire up the extraction with a specific trigger. For example, every time an issue is created within the sprint, you can trigger the script so it captures the latest status. Alternatively, using the scheduled jobs feature, you can set it to run at specific time intervals.

Step 3: Storing the data for each sprint in an accessible way

It’s great to know the current status of a sprint, but to be able to achieve data-driven planning and forecasting, we need to see the historic trend. The way we do this with ScriptRunner is by attaching the status we’ve just extracted to the sprint properties. This means that further down the line, when we want to look backwards at previous sprints, we just need to extract the properties of that sprint. And once you start storing and extracting a few, you’ve got your trendline and you can start extrapolating.

Extracting sprint properties

1summary = [Total: totalStoryPoints, Breakdown: [Users: assigneesInSprint,
3Issuetypes: issueTypesInSprint, Statuses: statusesInSprint,
5Components: componentsInSprint]]
7def postToSprintProps = put("rest/agile/1.0/sprint/${sprintID}/properties/storypoints")
9   .header('Content-Type','application/json')
11   .body([
13      summary
15   ])
17   .asString()
19assert postToSprintProps.status == 200

Step 4: Data analysis

Now that you’ve managed to extract your metrics using ScriptRunner, you can start your data analysis. Different organisations will take different approaches. For example, product teams may take responsibility for their own projects, or this might be centralised with the Jira Admins or in an analytics function. In any case, here are some ideas of things you might want to look:
  • Velocity trends - go beyond the high-level story points velocity chart and start plotting this by component, developer and any other breakdowns that may be particularly interesting to your team. This is how you’ll learn more about your team’s capacity and how different work plans lead to different velocities
  • Correlation analysis - this is where you want to see how your sprint goals affected your sprint outcome. Does a sprint that’s heavy on backend work always end up short of time? Do spikes lead to leftover story points? You can find out by plotting these data points to see how they correlate - and make planning and forecasting decisions based on the outcome
Feeling inspired? Pass it on!
Managing sprints is tough. You need to know your team’s capacity, and you need to decide on priorities despite everything feeling urgent. On top of this, there’s reporting that needs to be issued to the wider team. With the data held in Jira, and ScriptRunner helping you access it, you can learn from previous sprints and get on top of your planning.

Try ScriptRunner for Jira free