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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.