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...
A collection of tickets, feature requests, ideas and notes which are in a state prior to being implemented.
An outdated term. See backlog refinement.
An internal process by which a second developer checks all code before it it merged for release.
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.
The process of exploring ideas which aim to solve the problems outlined in a theme.
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.
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.
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.
Items that are high-impact and low-effort work. These are typically the no-brainers for inclusion.
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.
Items that are low-impact high-effort work. These are generally avoided, as they’re not worth the effort.
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.
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.
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:
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.
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.
An app (or collection of apps) that delivers value. It is typically a tool of some type.
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.
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.
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.
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.
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.
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.
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...