Glossary - Foxsoft

“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...

The Three Amigos requirement discovery workshop

Getting a shared understanding between stakeholders of why a change needs to happen and alignment on what a solution should look like.

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.

Approach

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.

Backlog

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.

Bikeshedding

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

Discovery

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

Documentation

The “triple threat” part three: Documentation

We’re looking at what we at Foxsoft call the “triple threat” to mission-critical and other software and apps.

Epic

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.

Estimate

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.

Formulation

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.

Guesstimate

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.

Day

A day consists of 7 and a half hours.

Week

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.

Incremental

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.

Maintenance

The “triple threat” part one: Maintenance

“We’ve not made any changes, but it stopped working”.

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

Overage

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

Phase

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:

Growth

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.

Tend

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.

Priority

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

Now

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.

Later

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.

Pending

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.

Product

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.

What is Product Management?

This series of posts about Product Management is designed to explain exactly what Product Management is and what the benefits are to the client and the developer.

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.

Roadmap

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...

Introducing the Product Roadmap

What is a product roadmap and why do you need one? What does the product roadmap do and how do you create it?

Seeing the future with your roadmap

Last time, we talked about product roadmaps, what they do and how they help you. We finished with an interesting analogy about apples.

Sizing

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

Spike

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.

Stakeholder

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

The “triple threat” part two: Technical Debt

Remember our client with the mission-critical software which has failed. Here we’re looking at the second of these.

Theme

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 Three Amigos requirement discovery workshop

Getting a shared understanding between stakeholders of why a change needs to happen and alignment on what a solution should look like.

Ticket

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...

Why we split user stories

Before we can start talking about why we split user stories, we probably need to discuss exactly what a user story is.