Multiple projects, one set of consistent tools, one roadmap?
A client wants to consider standardising on Jira and Confluence across their entire portfolio so I thought I'd implement these tools from Atlassian for all my projects first as a proving exercise. Previously I've used Assembla (really great tools but clunky and unloved) and GitHub (really great tools and community but questions over ownership intentions amplified by copilot) so I'm no stranger to these kinds of tools. I thought my write up might be interesting even though Atlassian was crowned "a very boring software company" in The New York Times for its focus on development and management software.
Atlassian has around 7,000 employees, almost a quarter of a million customers and around 10 million monthly active users. It is famous for Jira and Confluence and acquired Trello, Bitbucket and a host of other organisations. So its a pretty safe bet. Jira has a generous free tier too, which is welcome.
TL:DR If you like ticket tools, feature prioritisation, software product roadmaps, software assurance and devops tools you might find this interesting.
Jira
Getting started with multiple projects
The word project already sounds daunting. But projects are just containers with a name for managing linked tasks. Software projects are just containers with a name for managing linked tasks that concern a code repository. Projects help to visibly articulate committments to tasks by an organisation and its teams, and are a way to be able to explain the current statuses and often conflicting priorities to stakeholders such as managers or customers. Jira is a mature product, so it has a lot of customisation options for your projects so it is worth spending some time mapping them out before you implement them. You probably want to get this right from the start in a way what works for your organisation or your client.
My company has seven active projects going on at the moment. This is probably too many, but several are on the back burner. I decided to categorise my projects by the kind of work they are, Research and Development, Technology Strategy, Mobile Apps, Legal Technology, Software and Product Management. You could choose anything for your category information or even leave it blank. You might choose different categories depending on your organisations structure such as industry sector, (e.g. healthcare, education) or type of deployemnt (e.g. On Prem, SaaS) or language (e.g. Flutter, BASIC 😀 ).
Incidentally all my project names here are just code names. I've talked about this before but if you use code names then you can talk freely about a project without inadvertently disclosing information about it. It is always best to keep client or product names out of these tools as they often change. My code names are all names of colours. There's no particular reason for that. Codenames never change.
| Name | Key | Category |
|---|---|---|
| Cornsilk | CORNSILK | Research |
| Grapefruit | GRAPEFRUIT | Technology |
| Linen | LINEN | Research |
| Parchment | PARCHMENT | Mobile |
| Very Peri | VERYPERI | Legal |
| Wheat | WHEAT | Mobile |
| YellowGreen | YGREEN | Software |
Entering that information into Jira's project settings is simple. I chose 'Company Managed' as opposed to 'Team Managed' because I will need to pull in issues from other projects on my boards and need the ability to run parallel sprints. As much as I would like to use 'Advanced Roadmaps' I can't justify it for my small business and anyway it feels like an artificial freemium feature so I will work with basic roadmaps and see how I get on. I picked my own Keys as they need to be unique and maningful but Jira can do this for you if you wish. I get the feeling the keys will be important identifiers so wanted them to relate to my project code names. I added my own images for each project as the images in Jira weren't to my liking. I used an app icon generator to use the actual colour of the codename and add an icon that might be associated with the project. Here's my Jira All Projects page:
Now the projects are set up, lets add the detail to them so that it will be possible to see the issues at hand and make sense of them.
Boards
Boards in Jira show issues and their stage in your workflow using cards. Issues move from left to right to show progress and this provides visibility to the status. A board may be further divided into horizontal "swimlanes" representing different categories of work but this is not always necessary as boards can be filtered easily to show particular areas of concern so I've set this to 'none' in Board settings. Jira provides two template Boards - Scrum and Kanban. Where there is no sprint approach to work Kanban makes more sense. Where time-boxed sprints are used Scrum makes more sense. Each project has its own board. Here's the first one, which is empty because there is no content yet.
Creating a Cross Project Board
A Cross Project Board is going to be pretty vital both for my company and my client. They will particularly help provide management visibility of resource issues where one group of people works on multiple projects with sometimes conflicting deadlines!
To create one isn't intuitive at first but then the light bulb moment happens and you understand it.
- First, create a custom filter using
Filters > Advanced issue searchand save it. I called mine "Everything Everywhere All at Once" because this is a filter of all projects, all types, all statuses, and all assignees.
Atlassian — Jira — Filters > Everything Everywhere All at Once - Second, Create a board in one of your company-managed projects by choosting "+ Create Board" and apply the filter you created to the board by selecting "Board from an existing Saved Filter".
Atlassian — Jira — Create a board > Board from an existing Saved Filter - Third. Name your board, select the filter you created before and choose the project in which to save it or to save it to your profile.
Atlassian — Jira — Name this board > Everything Everywhere All at Once
Finished Cross Project Board
Thats actually brilliant. Now I have a single roll up board across all my projects. It took seconds to create and provides visibility over all my projects in one view without cluttering the individual project views with unnecessary tags or other artefacts in order to mash them into a single view! 💡
Issues
Issues are types of work item in Jira. Jira has a hierarchy for these issues which is simple enough. Epic > Issue > Sub-task. There look to be many ways to customise issues but for the moment I think thats quite enough especially as we have Project level boards and our 'Everything Everwhere' board to add to the hierarchy through which to look at these issues. Jira supports hierarchies above the Epic level such as Initiative and theme and customising the hierarchy configuration but you'll need a Jira software premium subscription and Advanced Roadmaps for that. This can be left as something to revisit if that flexibility becomes necessary.
Unique numbering of issues
It is a passion of mine to uniquely number issues or tickets in a project for traceability. Earlier I noted that Project keys looked important. And they are. They are one half of a unique identifiers for every issue in Jira. So for our "LINEN" project issue number 235 will be denoted as "LINEN-235" This is especially important where you have multiple projects but in any case unique identifiers for issues are vital to any project because they remove confusion about what is in or out of scope for the issue at hand. Scope creep is a bane for software projects and of all the measures to avoid it unique numbering is the easier to implement and has an immediate payback in clarity!
Issue keys are pervasive throughout Jira in labels, search results and saved filters, on cards on boards, in links and in the issue's URL. They quickly become a shorthand for discussions about an issue. I put issue keys in internal / developer release notes too, but never in external release notes say for the App Store or for Google Play as these are more of a marketing opportunity to tell potential purchasers that you update things often and theres good reason to click the "Get" button than a technical documentation set.
Issue types
Issue type schemes
Jira set up separate Issue type schemes for all my projects but I want them all to be identical so I deleted the ones it set up, then copied the Default Issue Type Scheme (their capitalisation) to a new scheme called "Everything everywhere" and then associated that scheme with all my projects. Customisations made to Everything everywhere will now be the same for all my projects.
Next we will get into the creation of a sprint, the issues in it and how its managed in Sprint setup in Jira.
References
See also:
