The problem

Project management teams, and software “power users”, generally enjoy the Jira user interface. They finally can configure it to be “close enough” to a specific problem they are trying to solve, yet also retain the full general Jira issue management capabilities. This works very well… for the right users.

But here at Expium, we keep meeting customers who have two user populations:

1. Those who care deeply about Jira, issues, general-purpose issue management – and who want information about their specific problem domain, seamlessly stored in Jira as the source of truth.
2. Those who care only about a specific problem domain, and don’t want to see anything about Jira or issue management topics in a problem-domain-centric user interface they use every day.

The solution

To meet the needs of both kinds of users in the same integrated system, Expium can implement a custom user interface to provide a domain centric set of features, while simultaneously keeping Jira as the source of truth behind the scenes. We have implemented such interfaces several times, with very good results. We now have enough experience to be able to offer an “off-the-shelf” project. In such a project, we create an working proof-o-concept custom user interface in front of Jira. We can do this for a quoted price, in a modest elapsed time. We call such a project a “Jira custom UI proof of concept”.

A good way to think about such an engagement is that it is one short pass through the development life cycle.  The effort is limited in time and scope, but reliably delivers an initial working result which demonstrates our customers vision. It can then be iterated on, either by Expium or by customer developers, to expand that vision.

Case study: Volkswagen ERL

Although much of our work is covered deeply by NDAs, you can read a written case study, and a video of Expium’s Michael McNeil talking about the project on the Atlassian Summit stage, below.

Volkswagen ERL: Customizing JIRA to Solve a Complex Problem

Typical scope of work

For a “Jira custom user interface proof of concept” project, the scope of work is typically something like so:

1. Meet with customer domain experts, typically for half the day for a couple of days. Understand enough to do initial, relevant work. Usually these meetings are online, occasionally in person.
2. Sketch (with a mix of code, drawing tools, and paper) what some of the most critical screens will look like.
3. Work with customer Jira experts to understand how the data on the screens is represented inside Jira (the “source of truth”).
4. Verify with customer domain experts that the ideas we have captured are the most relevant to their vision.
5. Implement: expand the most important aspects from mere static screens or drawings. Create working prototype code.
6. Integrate working screens with other static mockup screens.
7. Present the working prototype software to the customer, including source code.
8. Assist the customer with installation of the working prototype in their environment, to enable easy internal demonstrations.
9. Present a video demonstrating the working system, we have found this valuable especially when the prototype needs to be shown to a potentially wide audience around the customer organization.
10. Discuss future steps with the customer.

The bulk of this work is understanding the problem and creating working code. A proof of concept effort is not about creating a long requirements document – rather it is a quick, expedient effort to push aside any unnecessary detail and implement a working draft of the customer vision.

Technology

To get the maximum benefit from a short effort, we use technologies our team has extensive current experience with. Typically that will be (as of early 2017) Angular or React on the front-end. Typically there will be a Node or Java application server layer connecting the front and to the Jira backend data.

Team

To deliver a working result in a a short time, the Expium team on this kind of project consists of:

• Two core, highly experienced developers (developer / trainers)
• Assistance from a Jira workflow expert
• Assistance from other developers
• Assistance from a designer
• Assistance from a project manager

Schedule

The work happens over a 2-4 week period. To make it happen quickly, we need the right people available concurrently – so we work with our customer to choose the right start date carefully.

Location

The development work happens at our headquarters; with the meetings conducted with the usual remote meeting technology, or occasionally with a customer expert visiting. It is also possible to send a team to a customer site for this work – though that affects the costs and reduces the opportunity for other Expium team members to assist immediately.

Price

We charge a fixed, all-inclusive price for a fast proof-of-concept effort. Since the investment is known up front, there is no risk of exceeding an agreed budget, missing an estimate, and so on.

Where to go next

After a completed proof of concept project, our customer has working prototype software; but it is not a prototype in the sense of very poorly, hastily built code. It is built by, with the code review also reviewed by, our developers who (in their other work) not only use these technologies but also train on them. The prototype/proof of concept software is ready to serve as a starting point for a broader effort if needed.

If a development effort is warranted (sometimes the thing you learn from a working prototype, is that the idea is not worthy of major investment after all!) a customer in-house team could pick up a working prototype source code and run with it; or of course we at Expium can be involved in ongoing work.

Sounds good, how do I buy this?

This is just a blog post; there is no “buy now” button. Contact us about your project needs; we will discuss the specifics, then send you something similar to this post but in the form of a proposal – with a price.