A review on hosting JIRA on the free Amazon EC2 Micro Instance

Recently, we received an inquiry on whether it is possible to run Atlassian JIRA on Amazon EC2 Micro Instance. The free tier allows up to 750 hours of runtime each month.

Image from Wikimedia Commons

Image from Wikimedia Commons

We were curious on its performance and did some testing on it.

We did the setup with

  • RHEL 6 64-bit
  • Atlassian JIRA 6.1.2
  • Oracle JDK 1.7.0_45
  • Apache Tomcat 7.0.29
  • MySQL Database Server 5.1.69

The specs for the virtual machine

  • 6 GB of disk space
  • 590 MB of ram
  • Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz

The setup was completed successfully and we were able to create issues within JIRA. However, the performance seemed to be quite bursty as compared to our typical use. Sometimes an action is almost instantaneous, sometimes, a log in can take longer than 5 seconds.

In the end, we recommended him to consider upgrading the server specs or to take a look at Atlassian OnDemand. The cost of ownership will be lower with automatic version upgrades and data backups.

For a comparison on the differences between onDemand and self hosted, you can refer to our infographic.


Benefits of using Wiki for Requirements Documentation

Recently, Atlassian shared the details on how they are doing agile requirements documention with Confluence.

Atlassian Tiiks

It also included a well summarized list of the benefits below.

1. One page, one source, one problem
Keeping it simple. The requirements page becomes the “landing page” for everything related to the set of problems within a particular epic. Having something that is the central go-to location saves your team members time in accessing this information and gives them a concise view.

2. A page enables you to be agile
One of the awesome things about using a simple page to collaborate on verses a dedicated requirements management tool is that you can be agile about your documentation! You don’t have to follow a format every time – do what you need, when you need it and be agile about it. In fact, I encourage you to customise the Requirements Blueprint as you learn what works for your team so you can model your processes easily. Chop and change as required.

3. Dive in for context and detail
We often forget how powerful a simple link can be. We embed a lot of links within our requirements landing page. It helps abstract out the complexity and progressively disclose the information as it is needed to the reader. Linking detailed resources my included such things as:

  • Customer interviews for background, validation or further context for the feature
  • Pages or blogs where similar ideas were proposed
  • Previous discussion or technical documentation and diagrams
  • Videos of product demos or other related content from external sources

4. Living Stories: Stay updated, track and report on progress
I see a lot of customers do this as well. Once the stories have been roughly thought out – we often use the JIRA integration features in Confluence to link the two. From the page you can easily create your backlog stories. These are automatically embedded with two-way syncing from JIRA. So you instantly get progress reports of how the story is tracking with your dev team, right from your requirements landing page. Learn more.

5. Use your collective team and organisational wisdom
Especially if you are in a large organisation – documenting requirements Confluence makes it easy for other people in different teams to contribute and make suggestions. In the Confluence team, I’ve been amazed at the amount of times someone else from another team jumps into the conversation with a comment providing great feedback, suggestions, or lessons learnt from similar projects. It really does help a large organisation feel like a small team.

6. Make them dynamic and engaging
Use diagramming tools like Gliffy or Balsamiq to better communicate the problems to your team or embed external images, videos and dynamic content.

7. Collaborate!
The most important aspect of all this is getting everyone involved. Never write a requirements document by yourself you should always have a developer with you and write it together. Share the page with the team and get feedback. Comment, ask questions, encourage others to contribute with thoughts and ideas. This is also a huge asset for a distributed team.

As for the details on how to do it, you can check out the full blog post at http://blogs.atlassian.com/2013/07/agile-requirements-documentation-a-guide


Building a knowledgebase with Confluence and JIRA

JIRA is used by many organisations as a Helpdesk system to keep track of their user queries and requests. Over time, it becomes a valuable Knowledge Base. These solved cases will have details on:

  • how to replicate the error,
  • what was the root cause and
  • the desired solution

By opening up the Knowledge Base, it improves productivity by enabling end users to search for the solution first. If it is available, the end user will get his/her issues fixed and the Helpdesk team can handle difficult cases.

For organisations already have this arrangement, it can be further enhanced by tapping onto Confluence.

When tackling FAQs that require a detailed write-up, a new page can be created in Confluence via a standard template. As long as the JIRA issue is mentioned in the Confluence page (see red arrow in diagram below)

JIRA mentioned in Confluence


a corresponding link will be created in JIRA (see red arrow below)

JIRA mentions

Users can click on the link to Confluence to read the detailed solution.

The benefits of using Confluence are:

  1. rich content can be included (e.g. videos, screenshots, diagrams)
  2. content can be easily organised in user-friendly layout
  3. easy to search as FAQs can be organised by topics
  4. easy to find the solution in a page instead of digging long list of comments (in JIRA)
  5. protects sensitive information from public viewing

As a user, do you prefer the red pill or the blue pill?

Solution in JIRA
Comment in JIRA
Solution in Confluence
Confluence knowledge page

By investing a small effort in Confluence, it will reduce a big effort in JIRA subsequently.

You can start with a Doc Sprint to jumpstart your Knowledge Base with your own FAQs.


Using JIRA for Purchase Requests

A lot of people has the misconception that JIRA is used purely as a Bug Tracker. In fact, it can be used for many other purposes due to the key features (such as searching, dashboards, email notifications, workflows, permissions, issue types) provided by an Issue Tracker.

Whenever there is an item required (e.g. printer cartridges) or wished (e.g. OSIM uDivine), the person will create a new Wish in our Wishing Well project in JIRA.

The wish will be reviewed and fulfilled depending on the need, cost, urgency and usefulness. Periodically, we will review outstanding wishes as part of our Office Improvement Project.


OSIM uDivine


The good thing about using JIRA is that all wishes remains tracked so that we don’t miss out any of them. Wishers can also find out on the status of their wishes by logging into JIRA. And now, we welcome Well-wishers to come in to grant our wish for an Osim uDivine.