Agile Development Terminology

The Sprint

A sprint is a development cycle which lasts between 2-weeks and one month. Each Sprint should have a Sprint Goal and is made up of various work items (User Stories, Bugs, Tasks & Spikes) that should be accomplished during the Sprint.

Sprinting is a key component of the Scrum framework and there are x4 types of meetings (which are officially called ceremonies) that happen during each sprint cycle:

Daily Stand-up

This is a daily meeting that lasts no longer than 15-minutes. The purpose is for every team member to describe what they accomplished in the previous day what they are planning to accomplish that day and to raise any ‘blockers’ they might be facing.

Sprint Planning

Sprint planning is a meeting that happens on the first day of the sprint and involves the entire Scrum team. The purpose is to understand and agree on what User Stories/Bugs from the backlog can be delivered in the upcoming sprint, ensure the requirements meet the ‘Definition of Ready‘ and have a shared understanding of how the work will ‘get done’.

Sprint Review

This is where the work items that have been completed in the current sprint are demonstrated. The sprint demo is attended by the whole Scrum team and relevant stakeholders, and it happens on the final day of the sprint. The Sprint Demo can also be referred to as the Sprint Review.

This guide from Manifesto is an excellent guide to some of the practicalities of running a Sprint Demo.

Sprint Retrospective (Retro)

This happens after the sprint demo and before the sprint planning. It’s an opportunity for sprint teams to review what went well, what could be improved and what should be committed to be improved in the next sprint.

There are certain techniques that can be used to get teams discussing the sprint such as:

• Liked, Learned, Lacked and Longed For
• Mad, Sad, Glad
• Stop doing, start doing, continue doing
• Star Fish; Keep Doing, Less of, More of, Start Doing, Stop Doing

Backlog Refinement

Product Backlog Refinement is a meeting in which the Features and User Stories of the Product Backlog are discussed. The requirements and priority of the work items are refined and understood.

The Product Backlog Refinement meeting is an opportunity for the development team to highlight anything that they think are missing from the stories. The ultimate goal of a backlog refinement session is to get items into a state where they are sized and will meet the ‘Definition of Ready’ so that they can be accepted into a future sprint.

Product Backlog Refinement – Knowledge Hut

Product Backlog

This is a list of all the Product Backlog Items that are being considered for development and include User Stories and Bugs as well as Spikes and Chores. The Product backlog should contain items that help deliver the associated product roadmap and should be prioritised with the most important items at the top.

Example Product Backlog

Epics

Of all the terminology in the Agile Framework an Epic is the most misunderstood, and it can mean different things to different people. Some organisations use the term ‘Epic’ for a strategic level goal (more akin to a Theme) where as others try to shoehorn ‘Features’ into an Epic to neatly fit project management software such as Azure DevOps.

According to the Scrum Guide an Epic is a large body of work (for example ‘I want to be able to search for a product’) that can be broken down into a number of smaller User Stories. An Epic does not need to always include features, but it can if required.

Features

A Feature is a complete piece of functionality, that is part of a larger Epic or Theme. An example feature could be ‘Make an online appointment booking’ which could be broken down into constituent User Stories; Enter user details, Select time/date and submit details.

User Stories

User stories are short, high-level statements about what the digital product should do from a Users perspective. They contain enough information so that the development team can understand the purpose/value. User stories are often expressed in a simple sentence, structured as follows:

“As a [role or job title], I [want/need ____], so I can [end goal].”

User Stories must also have 1 or more ‘Acceptance Criteria’ which defines what need to happen to meet the requirements of the User Story.

Acceptance Criteria can be written in a more formal ‘Given, When, Then’ format or more simply with a bulleted list.

View some example User Stories

A Bug

Bugs specify when a web application isn’t performing the way it intended to. A bug is quite simply a failed acceptance criteria. A bug isn’t something that isn’t liked or wished it was done a different way – that is a new user requirement, differentiating between the two is critical for high-performing development teams.

A well written bug must document the steps required to take to reproduce it, as well as the expected outcome.

An example bug can be seen below:

Spike

A spike is a *timeboxed User Story that seeks to understand more about a problem or User Story before it is ready to be bought into a Sprint.

*A timebox = a set amount of time.

Story Points

Story points are a relative measure of size used by Scrum Teams that define how big or small any given User Story is. User stories are given points using the Fibonacci sequence of 1, 2, 3, 5, 8, 13, 20, 40 or 100. Story Points are usually assigned during backlog refinement sessions, but can be amended when more information about the task is understood.

Velocity

Velocity is a measurement of how much work is done during a sprint based on the number of Story Points that were accomplished during the sprint. Over time it can be used as an indication of how much work can be accomplished by the sprint team.

Cycle Time

Cycle time is the total time it takes to complete a specific work item. It is a measure of process efficiency and is different than velocity, (which is a measure of team efficiency). For example a User Story may have been assigned a low relative score for complexity but it may have to go through a complex release process and therefore has a high cycle time.

Definition of Ready (DoR)

This document defines when a user story is ready for the development team to start work on it. The DoR would typically include some guidelines for what is required in a user story, what is required for the acceptance criteria as well as what is required to report a bug.

Example of Definition of Ready

Definition of Done (DoD)

This document defines when a User Story can be considered ‘done’ and can been accepted by the Product Owner as complete. The DoD document usually includes details around the browsers and operating systems supported, code commits and unit tests to have been passed.

Example Definition of Done

Burn-down charts

A burn-down chart is a measure of work done vs. whats left to be done. When it is used on conjunction with the average velocity of previous sprints it can be used to predict what work can be completed with the time remaining.