Skip to main content

Planning development

docs image

Planning development

How new functionalities or improvements are requested and managed

Our goal is to make you adaptive to change. To achieve this, we want you to have direct influence on what we develop. Since new functionality and improvements take time to design, plan, develop and test, we offer you a way to plan ahead.

Quality in, is quality out​

We truly value the input of our customers, it's why we offer you development influence on our platform.

The amount of requests and suggestions to improve upon EVA we get however, make it necessary for us to dismiss requests when we feel they don't match our general vision. It's also why we focus on developing solutions in a generic way which can benefit the entire EVA platform. This means that sometimes your request can result in a solution that covers your need, but in a different way than what you envisioned.

The better the quality of your requests, the better and faster we can deliver results. Quality in, is quality out.

Your JIRA Board​

We work with JIRA to manage all development tickets - we'll provide you with your own JIRA board.

This is the place where you raise tickets, and group them into our releases. This board is yours to manage, which means you create the tickets and assign them the priority you think is needed.

We link your tickets to our internal board when we plan the four-weekly, five week release cycle with tickets from all our customers - as well as our own development initiatives. We communicate via the same tickets.

If you don't have access to Jira yet, please contact your New Black Project Manager

Types of tickets​

There are 3 types of tickets you can raise on your board:

Spikes​

  • All complex, layered requests start with a Spike. This is a ticket for New Black to design, but not yet develop, a full solution.
  • A spike is planned for a release, after which you can expect a proposal and possible planning for development in subsequent releases.

Examples include 'mini-projects' that require new features to be developed by New Black, across multiple apps and areas.

Stories​

These are for a Request for Change (RFC). Whether you wish your EVA system had a fancy new feature to make your job 10x easier, or if your business has new requirements, use the below format when composing a Jira ticket:

  • User Story: briefly convey the broad end goal from an EVA user's perspective. Use informal and natural language.
    • Focus on describing your challenge or desire – and not so much on your expected ‘software solution’. This leaves room for our team to creatively come up with something that might exceed your expectations.
    • e.g. As a (specific user), I want (x), so that (y) happens.
  • Current State: What is currently happening? Functionality might exist already but need improvement, or the functionality may not exist at all and needs to be developed.
  • Future State/Business Requirement: What do you want the end result to look like?
  • Justification: What benefits will be gained once moved to the future state? I.e., savings on time/cost/resources?

Bugs​

If a functionality in EVA doesn’t work as expected, then a bug ticket may be necessary. A bug ticket should include as many of these details as possible:

  • Description: Concise sentence explaining the issue.
  • Impact: What will happen as a result of this issue? Users cannot log in? Data is incorrect? Bad user experience? Describing this will minimize push back and prevent bad prioritization.
  • Steps to Reproduce: List the step to recreate the issue. Include screenshots, GIFs, or videos (ideally in-line within the ticket).
    • Expected result(s): What do you expect the outcome to be?
    • Actual result(s): What do you actually see when you follow the steps to reproduce?
    • Resolution: Steps taken to fix the issue.
Optional​
  • Root cause: The reason why the issue occurred.
  • Preventative action(s): Steps that can be taken or improvements that can be made to avoid this issue in the future. Mind that if an improvement is required, a new ticket must be created and linked to this ticket.
  • Email: Snippet from an important email, which is not available on the ticket.
  • Notes: Any other relevant information.

Planning your tickets​

To reiterate: You are principally responsible for writing and preparing tickets based on the guidelines above. To help you create optimal tickets however, a recurring ticket refinement meeting is planned with your TL on a weekly basis.

Once you feel your ticket is clear, use the Label on the JIRA ticket to flag it with the next release (AKA Drop) that is yet to start. So if New Black is now developing Release 51, you should request tickets for Release 52. Do so by looking for a tag labelled release-##, where ## is the number of release for your request.

This process will sync the ticket to New Black internal JIRA board where it gets further refined. An automated ticket comment will confirm the sync went through.

Internal refinement at New Black​

  • To determine storypoints for each item/request we have internal refinement sessions on Mondays. These weekly sessions include product owners, system architects, solution architects, scrum master, resource manager and developers.
  • The amount of Storypoints required for development of certain functionality depends on what's needed from design, its impact on other functions or features, impact on security and compliancy and covers creating the technical solution, testing the solution and its delivery.
  • As a request often touches on many parts of the application, accurately assessing the amount of work and complexity (culminating in storypoints) is not a five-minute job.
  • For this reason, it is common practice to only refine the items requested for the upcoming release, as requested by the client. After this internal refinement we communicate the story point estimates and leave the choice to our customers to add or remove items from the upcoming sprint.
  • We can refine more into the future, but this will take additional time and requires the backlog items to be described in detail. (e.g. the workload on a ticket will change if more information is added).
Quality in, is quality out

Keep in mind that when a request/item is sparsely explained, it is harder to estimate the work that needs to be done. This can result in a higher storypoint estimate.

Cut-off times​

  • See our Drops page for the schedule of our drops.
  • Internal New Black refinement are on a Monday.
  • To prepare for these in time, we look at tickets submitted until Thursday end-of-day, from the week before.
  • This means the final moment for you to request a ticket for an upcoming release is the Thursday, end-of-day, in the third week of the current release.
  • Any tickets submitted after this moment might be considered still, but we cannot guarantee anything.

Delivery of tickets​

  • Once done, a ticket will contain a comment explaining the developed solution, with a link to our new docs if relevant

Testing​

  • Please provide test results of developed tickets on JIRA within a week of delivery, so we can account for any changes needed.
  • Any later test results will still be looked at, but might call for a secondary planned ticket in an upcoming release.
  • See our documentation for more information about Testing EVA