Best practice: how to plan in Jira?

David Colijn April 7, 2017

I've been wrecking my brains to try to find the proper way to plan and track our software development in Jira, but I keep running into walls at every turn. Time to ask my peers! ;)


In short:

I’m looking for best practices and I think we all might learn if we can fire up a discussion on the planning process and what role Jira plays in this process? Basically the questions come down to this:


  • What does your version planning process look like? What steps to you take?
  • Similar question for customer projects including tailor made development?
  • How do you cope with changes? For instance bugs and unforeseen work that crosses and affects your sprints / planning?
  • What does your workflow look like?


Our case:

The bulk of our efforts goes to development of a large ERP application. Development of a major version takes several years, so in Jira this is now one big project with thousands of issues. The project keeps on growing as new (sub)versions are created and provided to our customers as continuous updates, so we don’t have a clear separation point where we could start a new project. Furthermore, we have some spin-off (web) development on the side which is integrated with our ERP API’s, sometimes to the extent that the lines are very blurry as to whether the issue should be assigned to the ERP or web team. Because issues are often co-dependent (i.e. ERP issue needs to be resolved before web issue can be started), we create these issues within our main development project and use components to separate the two. Issues are created basically come from three sources; (1) new version requirements / strategic development, (2) customer project (gap-)issues and (3) support issues / bugs.


How do we currently plan? Well.. our product managers have a pretty good idea on the outlines regarding features that need to be included in certain versions (either strategic or customer project issues) which serves as a non-formalized roadmap. Based on that, all foreseeable issues are created and placed in future sprints (2 week periods). All other issues (unforeseen, bugs, high priority changes, etc) are created continuously and added to sprints based on availability (est. time remaining) and/or priority. For instance; high prio (bug) issues will break into current sprint, but generally the policy is to add issues to future sprints depending on available time.


Our sprints are usually overbooked before the sprint starts: we have a general idea on how much an average developer burns down, so we plan each sprint for about 75% (e.g. 7.5 8-hour days out of 10). Usually, during our sprints, a lot changes due to unforeseen stuff (reopens, bugs, etc), and, furthermore I’ve calculated that currently our average issue overshoots the estimate with some 150%. Obviously, this results in a lot of unresolved issues which then bleed over into the next sprint causing workload to greatly exceed the sprint capacity before it even started. As a result, the version and customer project planning is shifting along without any real alarm bells ringing, because of the informal nature of the roadmaps and lack of overview.


Now, you are likely thinking: if an issue enters an active sprint, another issue with equal estimate should move to the next sprint. I agree in principle. Consider, however, that on average we create about 125 issues per week (500 per month) and we don’t have a planner / controller keeping track and redistributing issues (i.e. it could take a couple of days before anyone with proper rights has the opportunity to intervene).


The situation described above is just part of the challenge (because it concerns just the actual development tasks). After development come several other stages such as testing, patching, customer reviewing, etc (depending on the issue). The issues are automatically assigned to the reporter and thereby cleared from the developers board. One in every two issues is reopened and additional time required is hard to predict up front. What makes it even harder is that we can’t really predict when issues can be tested/reviewed. Thus, we can’t predict (1) the additional resources (time) required and (2) in which time period (sprint) this will likely fall.


I could go on for a while describing the planning challenges / situations we’re facing. Equally, even though I might not show it, I could also come up with several answers to these challenges based on several theoretical models how this process should ideally work. The problem with these theoretical models is that either the model assumes that planning is done up front, unforeseeable events do not exist and therefore planning remains static until life’s end and/or you have one or multiple full time planners / sprint leaders who continuously assess and adjust sprint planning every hour. This is obviously not feasible in many cases.


We’re not new to Jira (using it 7+ years) and I’ve also tried several add-ons like portfolio, bigpicture, tempo planner. So far none of them seem to offer the pragmatic low-effort solution that I’m looking for because they either lack some basic requirements or require a level of detail and daily effort that would take up to much time. Is our way of doing things so far off the “righteous path of agile”? Is that the reason why Jira itself and add-ons fall short in our situation for our planning purposes? Or am I just missing something?


Do you experience similar situations? Do you have answers?

2 answers

0 votes
David Colijn
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 27, 2022

Hi Edwin, I'm sorry to say we haven't truly "solved" it (yet). We've been tweaking and tuning the process gradually so that accuracy improves, but in the end there's still a large portion of our long term planning based on insights, gut feeling and estimated guessing. We also apply "reversed planning" which is essentially: picking a convenient date in the (far) future to build / release a new version and try to get as much of the roadmap done before that time. So a large timebox and with a kanban approach on the epics level.

It works for us, but still I would be interested in novel ideas to improve or do things differently.

0 votes
edwin vasquez
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 27, 2022

Just ran into this post and I found it interesting. How did you end up solving this planning issue?

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events