I wanted to write an article about what goes on behind the scenes here at SciChart about how we handle support, prioritize features for development and generally be transparent about our management processes! A few months ago we turned off the forums, and while we replaced chaotic forum and email support where tasks got buried or lost altogether with a much better ticket-based system, we did lose something – transparency – of what we are working on and how we are handling your requests.

Here at SciChart we do like to be open and honest. You, our customers are almost like our investors. When you purchase licenses you are literally funding current and future development, so we want to give you a return on investment by giving you the features and support you need. But how do we actually decide that?

The Support Workflow

The first step is we try to follow the Support Workflow. We receive support requests all the time. Since the Forums were turned off and support.scichart.com went live, we received over 500 tickets in the first 2 months! You can appreciate there’s a high level of demand here and we are kept busy by support.

The workflow we follow for support handling is below:

How do we handle Support? By using this Helpful Workflow!

Basically, it this is –

• If something can be done and exists in the library, we show you straight away! If we need to create a KB article or tutorial, sometimes we do that on the spot, or sometimes we schedule it for later.
• If something cannot be done, then if there is a known workaround, we provide it. Often we are able to do this and you are satisfied and able to take the workaround and use it. If a workaround is used too many times, we discuss as a team if we can make a feature out of it.
• If something cannot be done, but there is no workaround (or only an insufficient workaround), we create a feature request. These get prioritized later (more below)
• The more times a feature is requested, the more incentive there is for us to create a feature and an example, or KB article to demonstrate it.

What do we typically get asked on?

We typically get asked about things that SciChart does not support, or only supports via workaround. E.g. there are very few questions about the core features as demonstrated in our 70+ Live Examples or documented in our Knowledgebase. This tells us that we do a good job on demonstrating our core features and documenting them via the knowledgebase. If there’s something you need, it is usually something that is at the fringe of our feature-set, or something complex, so we are doing something right!

How to Feature Requests get Scheduled into Releases?

We currently run releases Month to Month. Meaning, we are aiming to release a minor update each and every month-end with the fixes and features you have requested in the previous month(s). This is in parallel with longer term R&D and major releases too!

Our current Release Schedule is setup into Monthly Iterations

After a while our monthly releases become hotfix releases, e.g. just critical bugs. For example, for SciChart v2.x this occurred after approximately 4 months of monthly releases. This frees us up to focus more on the major releases in the future. For instance, for the next few releases (SciChart v3.1, 3.2, 3.3), we plan a number of feature improvements as well as bug fixes that you report. After this time, we may opt to scale back on features and focus more on bugs as we do deeper refactors in-parallel for the next step-change in functionality.

How does a Monthly Iteration get Managed?

We use the brilliant JetBrains Youtrack to track issues and manage iterations in an Agile fashion. YouTrack is an Agile Project Management tool. Whenever we create a Feature Request or Task in our issue tracker, it goes into the issue tracker:

SciChart Task Board, provided by JetBrains YouTrack. There are currently over 2000 tasks in the Scichart issue tracker! That’s a rate of almost 3 a day since we started business!

Work is divided into Iterations, and we have chosen a month as our iteration cycle length. At the end of each iteration, our code is branched, goes through QA, final bug fixing, testing and is released. Any bugs found or fixed during QA or after are merged back into the main branch.

Keep It Always Releasable

What Version Control methodologies are we using?

We are following Trunk Based Development and all our main development is done off Trunk. e.g. Trunk is unstable, and every release becomes a branch. Bug-fixing, QA and testing is done on the branch. After release, the branch is merged back into Trunk. Sometimes Feature Branches are created but we aim to keep our code Always Releasable.

Tracking the Progress of a Release

Using the issue tracker, we can also track progress. Here you can find a screenshot of the v3.1 iteration (May 2014), showing our progress (Orange) vs. expected (Blue). As you can see, we’re tracking quite closely. Once we get near the end of an iteration, we can either extend the release date, or drop features and move to the next release.

SciChart v3.1 Burndown Chart, showing progress of the May 2014 (v3.1) Iteration

As you can see above we’re not far off schedule! Overruns can be handled in two ways:

• Either we drop features off the planned release (moving them to next release or cancel entirely).
• We delay the release.

Under no circumstances is release poor-quality software on-time a part of the options above 😉

So what will be in each release?

The actual features and fixes for v3.1 or any iteration won’t be announced until release time. Sometimes a feature has to be backed out at the last minute because quality is not high enough, so we don’t like to announce ahead of time. We take care that every release is of high quality. We don’t want to ruin our hard-won reputation as the Best WPF Chart by releasing shoddy software or by doing a poor job on support. So, great care is taken that each feature works, is tested and documented, either by KB article, release note or example.

We prefer to document by example as its live, you can see it, play with it, we can test-it each release, you can browse the source-code and it never gets out of date (you’ll never get a compilation error from out of date docs).

Feature Sponsorship – What if I need a feature now?

So there’s a feature you need but SciChart doesn’t support it yet? We decide our roadmap based on the following ranking:

• Critical nature of bug / Potential future value of feature
• Number of users that are affected / have requested it
• Any skewing factors such as Feature Sponsorship or potential license purchases

From time to time, one of our clients approaches us to sponsor a feature. This means we accelerate the development of a feature in return for an hourly or daily rate for ‘time and materials’ work, which is budgeted for and agreed in advance.

Our rates for such work are below. This is set to reflect the nature of demand and to encourage only the most urgent features from our customers.

Feature Sponsorship Rate Card

• Tech Lead / Manager (Dr. Andrew Burnett-Thompson): $150 / Hour
• Senior Developer: from $75 / Hour
• Developer: from $50 / Hour

How does Feature Sponsorship Work?

• Whenever we do this sort of work, we provide a rough estimate and begin work according to a set budget. At the earliest possible time, we refine estimates, e.g. if within a few hours we realise that we cannot realistically do this work without going over budget, we will down tools and communicate this to you until you have agreed a budget amendment, or cancelled the project. Billable work up to that point is chargeable.
• We retain the Intellectual Property over the charting aspects of feature sponsorship. This means, if you want us to add a new Chart Type, or new Interactivity Modifier, new plugin, or port SciChart to another platform, we have the right to re-sell this feature as part of the SciChart library. We make a clear distinction between IP of charting features which extend or are based on the SciChart library and IP of your product, which is clearly yours and we have no claim over, as according to our terms & conditions.
• We operate within the laws and jurisdiction of the United Kingdom and can draw up a clear NDA and contract before any work commences. You can have peace of mind that your work is being carried out in trustworthy hands.

Why would I pay that! Why not just wait for the Roadmap?

If you’re thinking this, then this service is probably not for you! We have a roadmap and we do use your requests to form the roadmap, but sometimes a feature, which is simply unpopular relative to current demand, gets deprioritized. If you really need it and soon then Feature Sponsorship is for you.

How Long will a Sponsored Feature Take?

Ultimately we cannot say without hearing your requirements, so if you are interested in this service, then please contact-us and we will give you an estimate.

• Some simple features can be added as an external piece of code in a couple of hours, however making it production ready (testing, documenting, thinking about all aspects of an API) can take longer.
• Some take several days or weeks depending on how divergent they are with our current architecture or road-map.

In any case we know SciChart better than anyone else and can significantly short-cut your development time by helping you with customizations to the Chart.