Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Best practice: how to plan in Jira?


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?

1 comment

Hi David

It sounds to me you have more of a process challenge rather than Jira problem. We have all the same challenges of trying to do too much in a sprint.

Our basic process is:

  • User story written
  • Team size stories for the next sprint  (1,2,4 or 8 points)
  • Planning session prioritise the stories and then only take in the number of points the team are achieving in a sprint
  • Sprint review do a retro and see what you completed and didn't achieve. If you planned on taking in 50 points and only completed 30, then don't take in 50 for the next sprint.

For Jira config itself we have a workflow linked to the board that tracks where the story is all the way to Done.

  • To Do
  • In Dev
  • Dev Complete
  • Ready for Test
  • In Test
  • Test Complete
  • Done

We also use sub-tasks to record what the major dev tasks are and testing tasks are to deliver the story. For exmample an 8 point should complete in roughly a week so sub-tasks are used to track that 5 day period. If its day 3 and nothing is done on the sub-tasks you have a problem.


From your post it sounds like Test isnt' included in your planning which is a different process. It would make it hard for you to determine potential level of bugs coming back into a sprint. 


Hope this helps a bit.

Hi Phil,

Thanks for your comment and yes, it helps! When other people are willing to share their process as well, then I'm sure we'll get some interesting insights that can benefit us all!


I have some followup questions for you though;

- I understand the basic sprint-planning process you've described. During these sessions you focus on what can be achieved in a certain sprint and I assume this type of planning applies to short term (less than a month from the planning meeting). How does this relate to your long term roadmap / planning?

- How much planning / scrum management overhead would you estimate you have (as a percentage of total team capacity)?

- From your last paragraph it appears that you have some system of predicting the amount of bugs which will likely occur in a given period, based on your testing process. Could you elaborate on that?


Thanks a lot!



Log in or Sign up to comment