Junari guide to terms and phrases

Here are some key terms to help you understand our processes:

  • Project Kick-off and Scoping session(s): Typically this is one x three hour session or two x two hour sessions prior to your project starting, during which we explain more about how we work and answer any questions you have, and ask questions about your organisational structure, and establish more details and priorities regarding your top-level requirements for context amongst other useful topics to set your project up for success.
 
  • Sprint: A Sprint is a fixed period of work within a project that typically lasts for two to four weeks, consists of set steps in order to deliver the systems you need, and usually finishes with a live release of your system for you to use.
  • Epic: Epics are the themes (i.e., functional areas) of a project to help categorise work to be done across multiple Sprints.  Each Task that we identify should belong to one Epic.  An example of an Epic would be “Marketing to Customers”.
  • Task: A task is the definition of a single piece of work, typically consisting of multiple elements.
  • User Story: Each “task” within has one or more User Stories that follow a rough format of “As a [role], I need/want to be able to [do/see something]”, e.g. “As a sales exec, I want to be able to view all leads worth over £10,000 which are likely to close within the next month.“
  • MoSCoW: Each task is assigned a priority based on the MoSCoW scale: Must Have, Should Have, Could Have, and Won’t Have.
  • Acceptance Criteria: Each task should have one or more Acceptance Criteria, which clearly define the minimum requirements for that task to be considered as complete.
  • Story Points: A measure of estimated effort for delivering User Stories, as detailed here.
  • Stretch Goal: A User Story / Task which we will endeavour to complete if other Stories / Tasks in a Sprint have been completed in less than the allotted time.
  • Sign-off: This refers to the process where you, as the customer, agree (sign-off) the Tasks that have been assigned to your next Sprint.
  • Backlog: The Backlog contains Backlog Tasks, which are those that are incomplete and not yet assigned to a Sprint.  These are often the starting point for discussing what will go into a new Sprint, and an ideal placeholder for future ideas.
 
  • Split Sprint: Split Sprints usually apply to the final Sprint of our Projects, and to any future Sprints after the initial project.  This is because for these Sprints we don’t usually have enough information to accurately allocate the number of Story Points required.  We run Split Sprints by getting to the stage where a sensible number of tasks have details against them (via a Requirements Gathering meeting with you), allocate Points against those tasks (via an internal Design and Estimation meeting) and then allow you to decide the number of points to be delivered in the Sprint (via a Planning meeting with you).
 
  • Staging: Our developers work on a copy of your system on their PCs, and then copy their work to a system for Junari can test, followed by a system for you to be able to test, before finally being made live on your system.  Each of these is known as a Stage.
  • Release: Release refers to the stages of us publishing your system to be available for you to test or use live.
 
  • Bug: This is where the system does not behave in a reasonably expected way, or doesn’t meet the Acceptance Criteria of a User Story / Task.
  • Minor Change Request: Most Sprints have a provision for Minor Change Requests from preceding Sprints.  Examples would be: adding an existing field as a column in a list, moving a piece of data to a different place on the same screen etc.  Points allocated for Minor Change Requests may be reallocated if not needed.