What are you talking about? – A digital delivery jargon buster
When you’re new to the world of digital project management, the sheer amount of jargon flying around can be a little intimidating. We often work with teams on their first major digital project or where it’s their first time using Agile methods, so I thought it was time we provided an explainer for the terms which are most commonly met with blank expressions. Is there any other digital delivery slang causing you confusion? Please do let us know in the comments.
A list of conditions that a piece of work must satisfy before it’s considered ‘done’. We use Acceptance Criteria to check that something works in the way you want it to.
The bits of the product (e.g. database, code) that sit on the server (or in the cloud), and which do most of the heavy lifting. As opposed to the front end (which your users see).
The list of things we need to do to build you a product.
Something that keeps you from getting a job done.
Something the product does that it wasn’t supposed to do. (Or something it doesn’t do that it was supposed to.)
A graph plotting the amount of (estimated) work left to do in the iteration/release against the time available.
The amount of time the team has available to work on a project.
Content Management System: software for creating and publishing content to the web e.g. WordPress, Drupal.
A daily meeting where the team comes together to talk about what they’ve just done, what they’re about to do, and any impediments to their progress.
We’re not sending this to the printers (usually), so we can change things. But sometimes we will ask that you say, “that sounds great, let’s do it”.
A demonstration of the working product at its current stage of development, usually held at the end of an iteration, which gives stakeholders the opportunity to feedback.
To move a task out of the current iteration due to changed requirements.
A task is Done only when it satisfies all the Acceptance Criteria.
An educated guess about the size of a task and how long it will take to complete, based on previous, similar tasks.
The interactive bits of your product, which provide value to the user or the business e.g. product catalogue, shopping cart, blog, search bar, social sharing buttons
A system which manages changes to a product’s source code, allowing multiple developers to work on it at the same time.
The process of fleshing out tasks in the backlog with more detail and ordering them.
Valuable actions that you want users to perform on your site/in your app.
A secure version of the HTTP protocol, using TLS/SSL encryption. A page secured with HTTPS encrypts any data your users send to you via forms etc.
IA (Information Architecture)
The structure of the content in your website or app – how bits of content are organised and linked together.
The process of improving an already-existing product, based on feedback from users. Can also refer to the time period in which the work is carried out e.g. “We’ll add a shopping cart in the next iteration.”
Code that’s run on a user’s device rather than on the server. On a web page, it often makes things move or change.
Project management software for collaborating on a product backlog and tracking issues/tasks/bugs.
An Agile methodology where workflow is visualised on a board, with tasks moving across columns from left to right as they get nearer to completion.
The time between a feature request being made and its delivery.
MVP (Minimum Viable Product)
A version of the product with the minimum functionality required to go live and start validating assumptions about user needs. We’ll then add to it over successive iterations.
Non-functional Requirements (NFRs)
Requirements for a website or product that specify how it works, not what it does for the user, like supporting certain browsers, using certain security protocols etc
Software which is created and maintained by a community of volunteers as opposed to a commercial company. Free to download and use.
Brief descriptions of your archetypal users which set out what we know about them and what we’re assuming they want, and which inform product development.
The process of deciding which tasks make it into the next iteration of work, or which features make it into the next release of the product.
The person in the project team responsible for making day-to-day decisions about product development. The Product Owner has intimate knowledge of the business and owns the product backlog.
A set of practices for ensuring the product meets the business’s quality standards, including testing and bug fixing.
The time period in which a new version of the product is delivered to end users, i.e. the version number goes up by one. A release might consist of several iterations of work.
Making a single web app which displays correctly across different sizes of device (as opposed to adaptive design, where different versions are created for different devices).
A meeting to look back over the last iteration, release or entire project to see if ways of working can be improved.
An Agile methodology in which work is done by a cross-functional, self-organising team, with a Product Owner and a ScrumMaster, in fixed periods called sprints.
The person in a Scrum team responsible for working processes: arranging and facilitating meetings, removing blockers, resolving conflicts etc. The team coach.
A messaging app used to help distributed teams collaborate.
Search Engine Optimisation: tailoring your website content and structure to perform better in search engine results for desired keyword phrases.
The name given to the time-boxed period (usually two or four weeks) in Scrum, in which a planned set of user stories is worked on. See also Iteration.
Ordering user stories according to complexity, and where they come in the user/customer journey. Story mapping is a technique which helps with planning.
A scoring system used for estimating the relative sizes/difficulty of user stories. Often measured on a Fibonacci-like scale (e.g. 0, 1, 2, 3, 5, 8, 13, 20, 40, 100) to reflect how estimates get less accurate as they get larger.
A board for tracking the team’s progress during an iteration and round which the daily stand up takes place. Often modelled on the Kanban board.
Test Driven Development: developing software by writing automated tests that the software has to pass before writing the code.
Testing the working software against the Acceptance Criteria to ensure that quality standards are met and that bugs are reported.
The path that a user takes through the product to accomplish their goal.
Testing working software, or a prototype, with real users to see if it fulfills their needs and expectations.
The name given to tasks in Scrum, which are described like this: “as a <user>, I want <feature> so I can <benefit>.”
The number of story points successfully tackled by a team in an iteration.
The act of assigning different version numbers to successive iterations of a product.
Project management methodology in which each mode of work (requirements gathering, design, development, testing etc) is carried out in order. As opposed to iterative models, where all modes happen in each iteration.
A sketch of a product’s user interface which describes the intended functionality (but not the visual design).
eXtreme Programming (XP)
An Agile software development methodology which prescribes a set of practices for improving product quality (e.g. pair programming).
Your Mileage May Vary (YMMV)
Warning that a solution which works for another business, technology or installation may not work in the same way for yours, e.g. “Clearing the browser cache normally fixes that, but YMMV.”
An optional first sprint of a project in which no working software is delivered. The time is instead used to create a product backlog and plan a real first sprint.