A way to visualise the work being done by the agile team. Often used in Kanban systems to see the work in progress at each stage of the system. This is an example of an Information Radiator.
The person who helps the team, department or organisation understand the values, principles, practices and mindset of agile approaches. In an agile team, the agile lead (the scrum master for scrum teams) is accountable for coaching that team.
The process of helping teams, departments and organisations better understand agile values, principles and mindset, as well as the specific practices of agile methods.
The manifesto for agile software development was created in 2001 to summarise the approach taken by the creators of agile frameworks. It highlights the need to put the emphasis on:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Twelve supporting principles were created at the same time:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Also referred to as:
- The Team
- The Development Team
Responsible for delivering the value defined by the product owner. Desirable qualities:
- Cross-functional – each member of the team has a specialism, with abilities to carry out secondary skills, with a T-shaped profile
- Self-organising – the team decides how to turn the requirements into working software, and who should do what on a daily basis
- Recommended size: 7 ± 2
Automated tests are scripted tests that run automatically. These are often included in a continuous deployment pipeline where they run every time code is committed and, if the tests fail, prevents the deployment of faulty code. Often built into a comprehensive regression test suite to ensure new changes do not cause defects in established code.
The activity of adding additional detail and analysis to items on a product backlog. This often includes:
- Estimating the effort
- Adding acceptance criteria
- Managing dependencies
These activities may be done by individuals, small groups, or by the whole team. They are usually carried out during an iteration/sprint, for work coming up in the future.
An ordered list of items to be completed. Backlogs should be visible so that they can be inspected and adapted. In Scrum there are two backlogs, one representing future work (Product Backlog) and current work (Sprint Backlog).
Behaviour Driven Development (BDD)
A form of acceptance criteria that allows technical and business people to define how a system should behave in a range of specific scenarios. Tests are based on scenarios, operating at a functional level and fulfilling a similar job to traditional regression tests.
The format for each scenario is:
Given <A set of preconditions, context, or starting point>
When <An action occurs>
Then <The system should respond in this way>
The rhythm of events in an agile team, typified by event taking place at regular, predictable intervals. For example, Sprint Planning taking place every two weeks on a Wednesday morning.
Continuous Deployment (CD)
An automated process where completed code is automatically tested and deployed to the various technical environment such as testing, staging or production. Usually combined with Continuous Integration and Automated Testing, which must be passed before the deployment takes place.
Continuous Integration (CI)
An automated process where completed checked in code is picked up by an integration build machine and the results fed back to the development team. Often used in conjunction with Automated Testing.
Also known as the daily stand-up or team synchronisation meeting, the purpose is for the team to inspect progress towards their goal, share relevant information, and adapt their plan as necessary. The timebox for this event is typically 15 minutes, and takes place at the same time and place every 24 hours.
Daily Stand-up Meetings
See Daily Scrum
Definition of Done (Done)
I list of criteria that must be achieved by the agile team to consider an item completed or ‘Done’. The definition of done is not item specific, must be able to be completed by the agile team itself, and needs to be specific enough so that it is clear whether it is achieved or not.
DevOps is an amalgamation of tools, techniques and process to align Development and Operations activities, using lean principles.
Allowing the technical design to emerge during the development process so information learned can be applied to the design. This is the alternative to a traditional Big Design Up Front (BDUF) model.
The process of forecasting the size of different items of work on a backlog. Agile teams often use relative sizing and story points.
Extreme Programming (XP)
An agile framework similar to Scrum with an emphasis on technical excellence and close customer collaboration.
A member of an agile team who is highly skilled in at least one area but has enough capability in other areas and can assist the team if that is a key task to meet the team’s goals. For example, a specialist front-end developer who can also write some automated testing scripts or do some database work. Also known as a ‘T-Shaped Professional’.
History of Agile
1948: The Toyota Way was codified, taking inspiration from a U.S. Grocery store, marking the beginning of the Lean movement in manufacturing
1995: Scrum was presented publicly for the first time, at the OOPLA conference
2001: A group of thought leaders created the Manifesto for Agile Software Development
A potentially releasable piece of work. In Scrum, this is one of the artifacts and represents the output of the latest sprint combined with all previous Increments.
A physical (or electronic) display of information that is designed to allow interested parties access to that information without the need for team member to specifically relay it. Examples include Agile Boards, digital displays showing service availability or the state of the latest software builds.
See Sprint Planning
See Sprint Review
A nmemonic to help set standards for the quality of analysis for product backlog items. By the time a backlog item reaches the point where it may be discussed at Sprint Planning, it should have the following characteristics:
- Independent – the item should not rely on future work to be worth building
- Negotiable – developers should be able to propose alternative solutions to deliver the capability needed
- Valuable – the value that an item brings should be defined and understood by all
- Estimatable – it should be possible to forecast the amount of effort needed
- Sized appropriately – small enough for several items to be completed in one sprint by one team
- Testable – it should be clear to all when an item has met the requirements
A method managing the flow of valuable work. The principles of Kanban manage and improve work across systems. It is not limited to software and has no constraints or timeboxes. Work is limited by a pull-system: new work can only enter when a space is made by completed work leaving the system.
Lean software development
An adaptation of the lean principles developed in manufacturing to make them relevant to software, taking the form of seven principles:
- Eliminate waste
- Build in quality
- Create knowledge
- Defer commitment
- Deliver fast
- Respect people
- Optimise the whole
Lean Seven Wastes
The seven wastes of lean software development are:
- Partially done work
- Extra Features
- Task switching
Mean Time to Restore
One of the possible value measures. A metric that measures the mean (average) time to recover after an incident.
When many people crowd round a single computer to work out a tricky problem. It is good for preventing blockers that would otherwise take time to resolve. Sometimes referred to as ‘swarming’.
The practice of planning an agile project with a backlog of features, and nominating each item:
- Must have
- Should have
- Could have
- Won’t have (this time)
Two team members working on the same computer to build a feature. One person ‘drives’ and the other person navigates, collaborating and watching out for errors.
Plan, Do, Check, Act is an iterative, four-stage method to repeatedly improve a product, service or process.
Planning Poker TM
A way of allowing a diverse team of estimators with different specialisms to apply story point estimates to items:
- Each item is discussed
- Individuals estimate individually using cards without seeing what their teammates picked (to avoid anchoring bias)
- Everyone turns over their card simultaneously
- Differences in opinions are discussed, enhancing the shared knowledge of the team
- A final number is agreed upon based on the shared information
An ordered list of items to be done to enhance or maintain a product. Items at the top of the list, which are likely to be worked on first, have had the necessary analysis for them to be worked on by the team. Items lower on the list will have had less analysis.
Also referred to as:
- Product Manager
- The Customer
Defines what is to be delivered, released, and optimises the overall value of the product. Desirable characteristics follow the DARKA model:
- Desire to be involved in the product
- Authority to make decisions
- Responsibility for the outcomes of those decisions
- Knowledgeable about the product, users, and market
- Available to the team to clarify requirements and make plans
A shared belief held by members of a team that the team is safe for interpersonal risk taking. It allow team members to be vulnerable in front of each other, for example by asking questions where they may otherwise be perceived as ignorant for not knowing the answer. A key ingredient for high performing teams.
The process of optimising and cleaning up code without changing the functionality. A key element in Test Drive Development (TDD). Refactoring helps reduce technical debt.
A process where items are estimated in compared to each other rather than given absolute values. Story Points are often used when conducting relative sizing. Alternative options include ‘T-Shirt Sizing’, where items are grouped into Small, Medium, Large, etc.
The process of forecasting when a set of features will be delivered or, for a fixed date, which feature will be completed by the required date.
A meeting to look back and identify possible improvement to how the team performs with regard to quality, tools, process and collaboration. For Scrum, see Sprint Retrospectives.
An agile product delivery framework comprising 3 roles, 5 events, and 3 artefacts and 5 values based on empirical process control. Work is limited by fixed-length sprints of 30 days or fewer.
Also referred to as:
- Agile lead
- Agile coach
Responsible for the process, facilitates and coaches, resolves impediments. Desirable qualities:
- Servant leader for the team, guiding without direct authority
- Enables the other roles to be effective without making decisions on their behalf
An event where representatives from different Scrum teams meet to collaborate and coordinate the integration of work across their respective teams.
Scrum Team Member
The scrum master, product owner or a member of the scrum development team. These are the people who plan and do the work in the team.
Scrum Three Pillars
Scrum is built on empirical process control on the basis that complex work is best managed through a process implementing:
- Transparency over the plan and progress made so far
- Inspection of the plan and the process based on the most up to date information
- Adaptation of the plan and process with a goal of maximising the value delivered
Scrum implements transparency through the artefacts, and all events enable inspection and adaption of specific parts of the process and the plan.
A servant leader is someone who supports the team and leads them without direct authority. Success of a servant leader is measured by the growth of the team and individuals within it.
A fixed period of not more than 30 calendar days during which an agile team deliver an increment of work. A Sprint is one of the five events in Scrum.
The list of tasks to be completed in a single Sprint/iteration. The team decide how many items to look to completed during the sprint and break the work down into tasks, which go onto the sprint backlog.
A Scrum event where the whole team get together to make a plan for the next sprint. The product owner brings the product backlog with items at the top in a suitable state to plan. Each item is clarified before the development team break it down into a detailed plan. The timebox for this event is typically 8 hours for a 4-week sprint.
Also known as the iteration retrospective, the purpose is to allow the agile team to inspect and adapt the process based on their experiences in the last sprint. The whole team identifies what went well, and what didn’t go well, before committing to at least one specific, actionable improvement to take into the next sprint. The timebox for this event is typically 3 hours for a 4-week sprint.
Also known as the iteration review or show & tell, the purpose is to allow collaboration between the agile team and the business. The work completed is inspected along with the current product backlog and release plan. All parties participate in giving feedback and discussing options with a view to adapting the product backlog and improving the plan based on new information. The timebox for this event is typically 4 hours for a 4-week sprint.
Squads are small cross-functional teams typically fewer than 8 that have a single focus or mission. They typically have an agile coach to guide them and a product owner to provide product direction. Unlike scrum teams, squads can use any agile framework they choose.
Teams size items relative to each other, in arbitrary units not directly tied to duration. The most common scale used is the adjusted Fibonacci sequence:
1, 2, 3, 5, 8, 13, 20, 40, 100
Working at a pace that can be sustained over the long term. Practices include working to a standard 8 hour day and under planning so that there is minimal reliance on overtime or similar. This generally results in less burnout, fewer defects and fewer project delays.
Test Driven Development (TDD)
A technical form of testing usually done by software engineers themselves, that involves writing a failing unit test, then writing just enough code to make it pass, then refactoring to improve the code.
Based on temporal motivational theory, a timebox is the maximum amount of time permitted for an activity, creating a sense of pressure to complete the work. It is the fixed amount of time allotted for an iteration or sprint of development. For example:
- In Scrum, the maximum amount of time for Sprint Planning is 8 hours. It doesn’t have to take that long, but can’t take longer.
- Iterations or Sprints have fixed timeboxes, which are chosen at the start and are typically kept the same length every time. If the team chooses a 2-week sprint, then more work is added if they finish early, and any incomplete work is put back on the backlog if not done within the 2 weeks.
See Generalising Specialist.
A simple but incomplete way of expressing requirements on a product backlog to allow the high-level intent to be understood and to foster a conversation between developer and customer. They contain just enough detail to decide how to prioritise, and whether to start analysing further. The most common format is:
As a <Role>
I want <Functionality>
So that <Benefit or value>
A historical performance metric that shows how much functionality was delivered at the end of previous sprints/iterations. Usually measured in story points, and used by:
- Product owners to predict release dates for items on the product backlog
- Development teams to predict what they can deliver in the next sprint/iteration
A type of Software Development Life Cycle (SDLC) model where the process starts with Requirement Analysis then does through System Design, Architecture Design, Module Design, Coding, Unit Testing, Integration testing, System testing and Acceptance testing. Depicted in a ‘V’ shape with ‘Coding’ at the base. The idea is that the analysis gets increasingly detailed, then it is coded, the testing starts very granular and completes with the acceptance tests. A tradition, non-agile model.
Volatile, Uncertain, Complex and Ambiguous (VUCA)
Agile approaches are likely to achieve better results than traditional approaches for work that displays VUCA characteristics.
- Volatility – Things are likely to change rapidly without warning
- Uncertainty – There is a lack of information available
- Complexity – There are many interconnected variables and decisions to manage
- Ambiguity – Available information is difficult to interpret
An example of a defined process where projects are delivered in large stages or batches. All of the analysis is done, followed by all of the design, coding, testing, etc. A high risk approach in a VUCA environment.
 ‘Planning Poker’ is a trademark of Mountain Goat Software