Adventures in “That’s Not How You Are Supposed to Use That”

As the resident wearer of a lot of hats, one such hat I wear is “Java Software Developer.” Some of the Java projects were ones that started from scratch. In that role, I helped build and design software architecture the app was built around. I got familiar with the patterns and plans of breaking things down into usable objects and functions. One of the other hats I wear is “Technical Lead” or “Scrum Master” on several Agile Teams. In this role, I have a hand in setting up more than one Jira project’s Architecture. Other work tracking software can likely be broken down the same way, but for simplicity, I will use the term “Jira” in this article. In a meeting, as we talked about the set up of a new work tracking Jira project, it suddenly hit me: we can use the same skills and terms to break down a new Jira project in the same way that we would a new software application — well, at least as far as the design architecture goes.

The project of that day needed a ton of automation, and it felt hierarchical. It was really giving the scrum team and customers a hard time trying to figure out how they would track all the work in Jira. So I started intentionally treating Jira issues as “objects,” workflows like “functions,” and custom fields like a “data design.” I listened to the customer as they described their process, and jotted notes down. Near the end of planning and design, customers and team members asked what I thought, and I stood up and started drawing on the white board: object diagrams, process flows, relationship pyramids, and the like. Everyone seemed on board, so I said I would formally draw up my thoughts.

After some time on my trusty laptop, I had a pretty accurate object diagram and process flow. The diagram looked familiar because it used all the same symbols that I use when I help plan a software app. These doodles quickly became core reference materials for the new Jira project layouts. In some cases the customers used them as resources as well. We used the drawings to streamline processes, guide the work plan, and highlight redundancies. It also let us know well ahead of time if something was too complex and needed some thinning. Part of the process could be handed off to a back-end script if it was repetitive.

When I talk about viewing Jira under the lens of “Object Oriented Design,” other Scrum Masters and ticket tracking software Admins tend to have the same reaction at first: “That is not how it’s supposed to be used!” That seems like a logical reaction, but after I give them the examples below, most of them agree it’s an interesting and valuable way to break down a new project. Part of the scrum leadership’s job is to break down tickets in consumable bits. Thinking about the project as a series of objects working together can help with the splitting and plumping work.

Nouns Vs Verbs

The first step to breaking anything down into is smaller parts is what I like to call “identifying the players on the board.” Imaging trying to win a game of chess if you had no idea what pieces were on the board. For an extreme example, can you plan out how to win a game if you have no idea what the game board looks like, or if the game board even exists? At the start of the planning session, draw a line down the middle of your note pad or white board. Label one side “Nouns” and the other “Verbs.” As the plan and project are discussed, one team member should pause and record every noun or verb as the talk goes on. Not every noun and verb will be used in the final plan, but its important to record them as they happen so the team doesn't miss an important part of the machine.

After the list is complete everyone then vets the Nouns. Example vetting questions might be:

• Is there overlap, and two nouns might really just be one?
• Are they general enough to cover all the common use cases?
• Are they all really nouns?

When reviewing and vetting, keep an eye out for missed or hidden relationships. Sometimes a verb might imply the addition of a noun you missed. In this part of the process, err on the side of generality. When the lists are vetted and thinned down, and everyone agrees, you have a list of reusable parts. The nouns should be converted into ticket or issue types, and the verbs should be converted into workflow or status types. By this point you should know what pieces are on the board and how they move.

‘IS a’ Vs ‘HAS a”

Next, you have to identify the relationships between the board’s pieces, but it’s still impossible to plot a path to winning the game. You need to identify how the pieces relate to teach other. How many of them will be on the board, and do the parts work together in some fashion?

The two key phrases for this part are “is a” and “has a.” We take the vetted list of our known players and go down the list asking at each object.

• What Contains this object?
• What is contained in this object?

For example we might ask “what contains a work-order,” and we find that the answer varies. It could be a contact object, or a project. We mark on the drawings any contains relationship as a “Has A” relationship just like we do in OO(Object Oriented) programing. If siblings are present we mark them with “Is A.” The textbook classic example of an “Is A” relationship is “A Pug is A Dog” it tells us a lot about those two objects. After a few rounds of setting up relationships its time to put things into a object hierarchy.

Hierarchy

The next and last part of the project organization is mostly already done. You need to lay out the objects in a structured hierarchy represented by the relationships you highlighted above. This will allow you to use features like issue linking to join tickets/issues to the parts they contain in the model. If two objects are listed as having a “Has A” or “Is A” relationship, they are on different levels of the hierarchy. After the layer cake is built, then it’s just a matter of hunkering down and building the project.

After going over those brief points I tend to get the an affirmative response. While I can’t say for sure that the idea is spreading, I do know that people I have talked to almost expect this sort of evaluation to be performed now. So I know it is providing teams with value. The more complex, the project the more time/tries it might take to get the project broken down into the correct chunks. I know it might seems like a lot of effort to front load, but putting a little extra effort into the planning stage of the project can save a lot of time later (or when setting up a work tracking program-or any project, really). There are loads of colloquial wit, aimed at beating home this idea. They are not wrong. Hopefully reading this helps you break down projects and problem sets, thereby making your life a little easier to plan and process.