| Table of Contents | ||
|---|---|---|
|
Overview
This glossary includes terms frequently used by both HEE and Transform.
...
| Word/Term | Meaning |
|---|---|
| AC: Acceptance criteria | A pass/fail set of descriptions of how a User Story can be tested to determine whether it has been 'done'. |
| Agile | A project management framework focussing on delivering small products as quickly as possible, then incrementally adding to them. This enables regular user input and 'agility' in embracing changing direction of the project in line with feedback and learning. |
| API: Application Program Interface | A set of routines, protocols and tools for building software, and defining how different software components should interact with each other. |
| Backlog | The list of everything that could be done by the project team if time was not a factor. This is usually subdivided into the Sprint Backlog and the Product Backlog. Occasionally, there is a further subdivision Next Up, indicating the highest priority items of the Product Backlog to work on, once the Sprint Backlog is complete |
| BDD: Behaviour Driven Development | Aims to help focus development on the delivery of prioritised, verifiable business value by providing a common specification language, that spans the divide between business and tech. |
| Blocker | Something that prevents one or more stories being completed. It is the job of the Scrum Master to help remove these blockers. |
| Burndown | A chart that shows the amount of effort or number of stories that are in the backlog and how they are being completed over time (usually a Sprint). |
| Confluence | The web application where we store all the project information and documentation that supports the backlog - linked to Jira. |
| CRUD: Create, Read, Update, Delete | The four basic functions of persistent storage. |
| Discovery | The first phase of a project approach (before alpha). |
| DBC: Designated Body Code | |
| DoD / Done: Definition of Done | Sometimes a statement within a User Story, describing what 'Done' looks like, more usually expressed as a set of Acceptance Criteria. DoD can be applied to larger pieces of work than just a User Story. It can be used when working with Sprint Themes (a collection of User Stories around a central subject - either from a user perspective, or focussing on specific area of code). |
| Epic | The highest level of requirement in the backlog - this is too big to be worked on within a Sprint and needs to be refined into one or more User Stories. |
| ETL: Extract, Transform, Load | A way of taking data from one place/system and re-presenting it in another. |
| Incremental / Iterative development | These terms are often confused, leading to unintentional breakdowns in communication. This article really eloquently explains these two concepts visually. Well worth a read. |
| Iteration | See "Sprint". |
| Jira | The web application where we store the backlog, run the Sprints and communicate on progress. |
| MMF: Minimal Marketable Feature | An incremental layer that can be added to the MVP and released to the public. |
| MVP: Minimum Viable Product | The simplest version of the product that could in and of itself be deployed into a public environment as quickly as possible in order to provide value to the customer and to provide the Agile team with continuous feedback (which can be evaluated, prioritised and fed back into the Product Backlog. Onto this MVP, we layer on MMFs to continually enhance a released product. |
| Product Backlog | Those stories that are either: – initial placeholders for work that will be worked on in the future, but haven't been defined sufficiently yet to bring into a Sprint; or – fully formed stories that are not deemed priority items to be worked on in the current Sprint. |
| PO: Product Owner | A member of the team that owns the Product Backlog and advices on prioritisation of work. |
| Scrum | A project management methodology within the Agile Framework. |
| SM: Scrum Master | A member of the team who facilitates the activities so that the Sprint can complete. Also monitors and reports on progress to the wider stakeholders. |
| Sprint | A short period of time (from 2 - 4 weeks) in which a team work on a set of Users Stories that they commit to completing during Sprint Planning. A 2-week Sprint is the most common cycle. Sometimes called an iteration. |
| Sprint Backlog | Those stories taken from the Product Backlog that the team has committed to completing, during Sprint Planning, within the current Sprint. |
| Sprint Planning | The meeting at the start of each Sprint where all the commited team agree what tasks/stories should be brought into that Sprint. |
| Sprint Retrospective | A meeting at the end of every Sprint where the Agile team gather amongst themselves, and analyse what went well, what they could have done better, any impediments to progress, and take actions to be more productive in the next Sprint / remove any impediments. |
| Sprint Review | A meeting at the end of the Sprint to review what was achieved - i.e. to celebrate success with stakeholders outside the team, and invite their input into future direction for the project. With a big stakeholder group, this can be split off into a separate meeting for POs and specific Devs to present (sometimes referred to as a 'Show and tell', but which should also invite comments too). |
| Standup | The daily meeting at which all commited team members update the team on their progress. |
| User Story | Often shortened to just 'Story'. A collection of sentences that capture a single requirement of either a system or a user. This usually follows the format of identifying who the story is for, what it is about and why it is important: As a [who], I want [what], so that [why]. For example: As a bank manager, I want people banking with me to be able to withdraw money from their account no more than the limit of their debit cards, so that I can control overspending on their accounts. A user story that someone can start working on is accompanied by several Acceptance Criteria. |
| TDD: Test Driven Development | An approach to development that begins with determining how the 'code' will be tested, then building the code to the tests. |
| Velocity | The term used to describe measuring the progress of a Sprint within the team. And the likely ability for a team to complete upcoming work. Note: this is not for presenting to stakeholders outside the project team. |
...