“Too many chefs”

Too many people are trying to control, influence, or work on something, with the quality of the final product suffering as a result.

Acceptance criteria

A list of things that must be implemented for a user story to be considered complete.

You can learn how we agree on the acceptance criteria with our clients in our blog...

Account Manager

Foxsoft’s internal representative for management of an Account. They’re typically responsible for dealing with client issues and enquiries, including drafting proposals for work and conducting quarterly status updates.

ADR (Architecture Decision Records)

A document that captures an essential architectural decision made along with its context and consequences. We use them to justify all the decisions we make when building projects and to help answer questions which may arise about said decisions in the future.


Supplied by a developer, an approach is a back-of-the-envelope explanation of how a feature request can be implemented, an Estimate, and other auxiliary information, such as questions for the client.
They exist to give the client confidence we understand a request and information on how long we think it’ll take (and thus, how much it’ll cost). Based on the information, a client can proceed or drop the idea.


A collection of tickets, feature requests, ideas and notes which are in a state prior to being implemented.

Backlog Grooming

An outdated term. See backlog refinement.

Backlog Refinement

The process of translating a feature request into an actionable feature specification. Typically consists of running each request through a process of discovery and formulation.


Also known as Parkinson’s law of triviality, it describes our tendency to devote a disproportionate amount of our time to menial and trivial matters while leaving important issues unattended.

Code review

An internal process by which a second developer checks all code before it it merged for release.

Concrete Example

A term typically used in behaviour driven development, concrete examples are non-abstract ways of describing the functionality of a feature. They typically use real-world examples of what needs to happen under specific conditions.

Design Squiggle



The process of exploring ideas which aim to solve the problems outlined in a theme.



A collection of user stories (and other information) grouped by a common outcome. We don’t tend to use epics at Foxsoft, instead preferring to use themes.


An indication of how long a feature will take to deliver. These are provided in hours and include all aspects of the task, including prep, coding, code review, QA, documentation, testing and deployment.

We cannot estimate any work before the formulation step, but we can provide a guesstimate or perform a sizing exercise.

Feature Request

Originating from a client, a well-formed feature request will answer a set template of questions designed to supply just enough information to allow a developer to put together an approach and provide an initial estimate.


The process of taking the artefacts from the discovery session and turning them into a fully defined user story so that an estimate can be provided.

Good standard

Each app is different, so defining precisely what a good standard is, is difficult. Work of a good standard will typically match – and, where possible, improve upon – the standard set by the rest of the app in all things, be that the quality of the code, specs, and environment.


This is a back-of-the-envelope figure, designed to be calculated as quickly as possible to give clients an idea of how much effort will be involved in implementing their feature request – and, as such, how much it’ll likely cost – so they can decide if it’s worth progressing with.

They are typically provided as a range in the most appropriate time units (typically days or weeks). See sizing.


A day consists of 7 and a half hours.


For internal members of staff, a week typically consists of 4 days and equates to 30 hours (this accommodates one day per week for internal duties).

For contractors, a week typically consists of 5 days and equates to 35 hours.

Impact/Effort Matrix

A tool designed to help prioritise work. Using the scores associated with the t-shirt sizes, it shows all work requests in a grid, with their placement compounding the impact and effort scores. Depending on the quadrant it lands in, a task will be easy win, big bet, incremental, or money pit.


Easy Win

Items that are high-impact and low-effort work. These are typically the no-brainers for inclusion.

Big Bet

Items that are high-impact and high-effort work. These carry some risk but have a big payoff and should be second in priority order.


Items that are low-impact low-effort work. These are easy to do but with a minimal payoff. These items are generally picked up here and there, among other items.

Money Pit

Items that are low-impact high-effort work. These are generally avoided, as they’re not worth the effort.

Effort Score

The value given to an item to identify how much relative effort it will take to implement it by the development team. These are recorded as t-shirt sizes.

Impact Score

The value given to an item to identify how much relative value the completion of the item will bring, i.e. how much of an impact it will provide? These are recorded as t-shirt sizes.


MoSCoW method

A prioritisation technique to rank the importance of feature requests, individual aspects of a feature, and feedback from Code Reviews. The term MoSCoW itself is an acronym derived from the first letter of each of the four prioritisation categories:

  • Must have
  • Should have
  • Could have
  • Won’t have


Clients who have used up all their Support allowances may go into overage, which comes with additional fees. Also see support.


Products tend to cycle between periods of active development and quieter periods of just maintenance.

These are known as phases and are organised into the following statuses:


A product in active development, with new features released and improvements added. During this phase, you can expect regular product management activities like roadmapping and user story refinement. Ongoing maintenance (as defined in tend below) will also continue.


A product which is not in active development. Much like you would tend to a garden to keep the plants watered and weed-free, applications also require ongoing maintenance to keep the app healthy and stable.

PRD (Product Requirements Document)

A living document which contains a high-level overview of the requirements of a project, aimed at stakeholders from all levels. Its purpose is to communicate what is being built, who it is for, and how it will deliver value to end users and the business.


The order in which we aim to tackle themes. Organised into the following statuses:


Themes in active development. We typically know the most about the problem and our approach to solving it. Most tickets associated with this theme will either be fully refined and working on or in active refinement.

Typically we run a work-in-progress (WIP) limit on themes in the now status based on the number of developers available.


Themes which are in line to be picked up when a gap appears in the now status. We’ll typically know more about the problem to be solved than themes in the Later status, but not as much as ones in Now. May have some refined tickets, but typically nothing has been picked up for development.


Themes with a lesser priority than those in Next. Although a rough outline of the problem to be solved will have been defined, that’s about it.


Themes we know are needed but haven’t given any thought to them. They will be moved into Later once the problem to be solved as been outlined.

Priority Flags

Used by the client to identify how important a piece of work is. In order of priority, the options available are Urgent, High, Normal, Low, or nothing.


An app (or collection of apps) that delivers value. It is typically a tool of some type.

Product Manager

Foxsoft’s internal representative for management of a product. Typically responsible for understanding stakeholder requirements and preparing them ready for development. They often work directly with the product owner to help set a shared understanding of the product and its vision.

Product Owner

The client’s representative for the ownership of a product. A single point of contact at a company responsible for providing relevant information about the product from the client’s perspective. They typically handle internal feature requests (where applicable, filtering out unimportant ones) and communicate them to the product manager.

Product Vision

A quick-to-digest statement describing the overarching long-term mission of the software application. Vision statements are aspirational and communicate concisely where the product hopes to go and what it hopes to achieve in the long term.

QA (Quality Assurance)

The internal process of checking a developer’s work to ensure they’ve completed it to a good standard and met all the required acceptance criteria, prior to being deployed for client testing.

QC (Quality Control)

A final check as part of the production deployment process to verify there are no last-minute issues.


The roadmap exists to share the vision and set the direction for the product. Unlike a project plan, it isn’t concerned with the minutia of specific features or release dates. Instead, it exists to document a product’s themes’ alignment on feature development.

You can learn how a roadmap benefits your business in our blog...


The high-level act of judging the size and scope of a project to provide a guesstimate.


A type of ticket designed to gain the knowledge necessary to understand a requirement better, increase the reliability of an estimate, and reduce the risk of a technical approach. They often entail a short burst of development work to answer a question, which is then thrown away.


A broad term describing people with interest in a product’s outcome. These can include executives, project sponsors, customers, and users

T-Shirt Sizes

Are a way of indicating the value of something relative to other items. They typically consist of values Extra Small, Small, Medium, Large and Extra Large (each has a numerical representation ranging from 1 for extra small to 5 for extra large).

As a general rule of thumb, anything classed as extra small could be seen to be too small, in which case it could be merged in with another user story. Likewise, anything extra large should be seen as too large and broken down into smaller user stories.

Technical Debt


A theme is typically a problem to be solved. When discussing features and requests (typically represented as user stories), it’s essential to understand which theme they relate to so understanding the problem being solved can be understood.

Three Amigos

A term used to describe a meeting where the three main disciplines are present:
  • Someone representing the business needs of the client or product owner
  • Someone representing the technical side / a developer
  • Someone representing the end user / a product manager
During a Three Amigos meeting, user stories get fleshed out, initial acceptance criteria are established, and estimates of effort are defined.


The representation of a unit of work with a clearly defined outcome, tracked via our project management system. They could be support tickets, user stories, feature requests, ideas, or spikes.

User Story

A placeholder for a conversation defining a feature requirement. These are often the starting point of a feature specification (when combined with acceptance criteria, etc…), but in the early stages serve as a loose outline of what’s required and why.

You can learn about the evolution of a user story in our blog...