Jira organization for micro projects / features

[cdkben]

I work in a very small group that has roughly 6,000 micro applications for approximately 2000 clients. We also support these micro applications (features). Our charter is to provide custom features for our core products. The features are NOT dependent on a core relase (i.e. they are standalone). We are trying to organize our business process in Jira effectively. Custom features take anywhere from 4 hours of development to 100's of hours. We use one giant Jira for all developemnt groups, so we've been exploring ways to organize our custom features without adding 6000+ projects to Jira. We have also looked at adding components for each application, but that doesn't seem to be manageable having a drop down with 6000+ components to chose from.

I am looking for some guidance on how to organize our Jira space in a sane way, without adding 6000 projects to Jira. The company is also looking to use Jira to roll up KPI metrics across all development groups in the organization.

Any suggestions would be greatly appreciated.

[Boris Berenberg - Atlas Authority]

Are there any hirearchies to either the tech, the customers, or your internal processes that you can think of beyond what you have listed?

For example, can these be split by the skills required to work on them? So you have 1k iOS 1k Android 1k Swift etc 

[cdkben]

Thank you for your reply.

Not really, the workflow and tech is basically the same for each "feature" with the only difference being the actual feature change.

Each feature is tracked in source control based on a unique request number.

Each FeatureID contains the code for that feature request. The features are all customer specific by nature as the core app doesn't provide the functionality the client is looking for.

Workflow:

1. Client requests feature
   1. Create eval story in backlog
2. Feature is evaluated and client is issued a quote
   1. eval story added to a sprint
   2. eval completed
   3. quote issued
   4. story done
3. If quote accepted, create dev story in backlog
4. dev story added to sprint
5. dev completed
6. documentation completed
7. feature delivered to client system
8. story done

Firefighting stories added in for support of said features if bug is discovered.

Work in 2 week sprints, evaluations are stories part of an evaluation (neverending epic). development are stories part of a development epic (also neverending).

Our goal is to have epics that actually end, but every direction we're looking at is adding copious amounts of admin overhead to the process and considering the size and scope of the features.

[Boris Berenberg - Atlas Authority]

So what happens after step 8? Do you never touch it again? Does touching it again mean going through the whole process all over again?

It sounds like you guys just need 1 project, each of these should be a single ticket, and what you described above should be the workflow for it.

[cdkben]

After step 8, it's complete. If there is a bug found, it's handled as a support ticket (we warranty our code) and is added as a firefighting story so it can be addressed asap.

In the case where a client want the feature changed, the process starts over with an evaluation. The unique id is still used to track the feature (internal tracking system), but for the agile / jira process it's treated as a new evaluation and goes from there in the workflow.

[Boris Berenberg - Atlas Authority]

Yeah I would definetly just track each one as a ticket then. If they need revisions, leave the parent ticket open. Create a new ticket and link the two together.

The harder question is how to track the 2k customers. Are they identified by a domain? some id? peoples names? company names? Is there a programatic source for them anywhere?

Are you on Cloud or Server?

[cdkben]

In the Jira space, we don't currently have a need to track the customers as far as I can see. That is handled by the internal tracking system with the unique id. The id ties together the customer, their system, and feature(s) on the system. Customers can have multiple features, but that is all tracked through our internal system. Each customer system is either on prem or housed in a datacenter (most are hosted in a datacenter).

We are getting pushed to move to a more "standard" way of using Jira in term of our features being "projects" which for our use case doesn't make sense, which is why I am here. Trying to see if there is another way to re-tool the way we use Jira to conform to the way our core apps dev teams use Jira.

I appreaciate your input!

[Boris Berenberg - Atlas Authority]

The right way for you to use it is as I described above. The power of JIRA is it's flexibility. The methodology above will still integrate with your CI and VCS tools. And it will work just fine with the Agile tools built into JIRA. Your features are not what JIRA calls a Project, and thats why they don't fit into it. It's a problem of terminology used by your org vs terms used in Atlassian tools, not functionality.

[cdkben]

Great, at least there some validation this process isn't too far off base. I really appreiate your time and input! Thank you!