In this post you’ll understand what is the Agile concept and the meaning of all the essential terms and roles used on a daily basis in Agile projects.
We often get carried away and start using very technical jargon, acronyms and so on. This creates barriers which prevent us from reaching our interlocutor and make it more complicated to hold people’s attention and get the message across. That’s precisely the reason of this Agile glossary!
Agile Glossary [Alphabetic order]:
This infographic shows a general scenario of the Agile process that I’ll describe below: how to work using Agile, what are the main roles and the terms you need to develop a project within this philosophy.
You can save it as well, I assure you that it will help you to have a complete outline of the work in Agile.
A
What is Agile (and what it’s not)
Agile is a philosophy or movement. An alternative to traditional waterfall projects management.
A team that collaborates actively in small iterations to make specific updates to products and services.
It provides a mechanism for constant feedback on evolution. It grants added value to customers right from the 1st iteration.
It covers various methods which can be used to create or adapt our own processes: Scrum, Lean, Kanban, XP…
Agile philosophy is based in 4 values:
- Individuals and Interactions over processes and tools
- Working Software over comprehensive documentation
- Customer Collaboration over contract negotiation
- Responding to change over following a plan
Agile is not carried out for the customer but rather WITH the customer.
According to those 4 values, the Agile Manifesto has 12 principles:
- Customer satisfaction by early and continuous delivery of valuable software.
- Welcome changing requirements, even in late development.
- Deliver working software frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the primary measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Best architectures, requirements, and designs emerge from self-organizing teams
- Regularly, the team reflects on how to become more effective, and adjusts accordingly
Agile Coach
A trainer, mentor, facilitator. Helps the Scrum Teams. He helps the team to re-think and to change the way they developt themselves as a team. He also motivates the change and make it possible.
- Evaluates the maturity of the organisation in Agile and guides it to higher levels of Agility and effectiveness at a sustainable pace.
- Does everything possible to ensure the teams are self-organised in their work.
- Implements practices that promote communication and improve decision-making and conflict resolution.
- Promotes the use of collaborative tools to facilitate transparency and synchronisation of work.
- Works to eliminate obstacles to increase organisational agility.
- Builds a safe environment where problems can be freely raised, with an emphasis on collaboration and resolution.
- Facilitates the work without imposing, assigning or dictating how it is delivered.
- Helps with internal and external communication, improves transparency and sharing of information.
- Supports and educates the Product Owner in Agile Transformation, particularly with respect to refining and managing the Product Backlog.
- Works with Scrum Masters / Agile facilitators to guide the general organisation as to how to use Agile practices and values and promote their use.
- Performs skill-building sessions and workshops for Agile teams.
Requires high-level facilitation, training, leadership, conflict resolution and 3 years’ minimum prior experience as a Scrum Master.
Artifacts
The resources-tools used to represent work or value. The purpose is to enhance transparency and identify opportunities for improvement: Product Backlog, Sprint Backlog, Monitoring the Sprint Progress and Increment.
B
Burn-down Chart: Pending Tasks
Graph showing the progress of the Sprint: points representing work performed and pending on a time line which allows us to see how much time is left to finish the sprint.
This graph may be consulted using the digital tool at your disposal (Jira, Taiga…) or may be calculated using the data on a physical board.
- Chart reflecting the time available to complete the work of the Sprint.
- Axis X: days of duration of the Sprint.
- Axis Y: amount of committed work.
- If it is below the ideal line, it is on its way to achieving the Sprint Goal.
Other charts exist to view the team’s progress.
The Development Team monitors this remaining work, at least in each Daily meeting to manage progress and ensure that the Sprint Goal is achieved.
C
Ceremonies
The Scrum Team meetings are called Ceremonies or Events, but Ceremonies ir more common. They are: Sprint Planning Meeting, Daily Scrum, Product Backlog Refinement, Product Backlog and Sprint Review.
Sprint Planning
Initial meeting at the start of each Sprint, with the aim being to determine: what will be developed? What is the priority?
- Initial meeting of the Sprint, where the Product Owner discusses the Sprint Goal with the Scrum Team and the Scrum Master.
- Agreement is reached on goals and work.
- The team estimates the work that may be completed in the Sprint for the items prioritised in the Product Backlog.
Duration: maximum 2 hours per week of the sprint
Participants: Product Owner, Scrum Master, Scrum Team
Daily
Brief daily meeting of the team + identification of obstacles.
Each member of the team answers these three questions:
- What did I do yesterday that helped to achieve the Sprint Goal?
- What will I do today to help achieve the Sprint Goal?
- Do I see obstacles to achieving the Sprint Goal?
Duration: maximum 15 mins.
Participants: Development Team, Scrum Master
Refinement
Revision and redefinition of the functionalities prioritised.
- Revision and redefinition of the Product Backlog based on new information/requirements.
- Re-estimation of existing items based on new information previously unknown.
- Addition of new Product Backlog items or removal of some existing ones.
- Division of large items into other small ones (Epics -> User Stories).
- Estimation and prioritisation of new items.
- Revision as to whether the user stories prioritised comply with the Definition of Ready (DoR), with the objective of working only on the stories that grant greater value to the business.
Sprint Review
The Scrum Team presents the work carried out, working Software.
- Strategic meeting to analyse the increment completed by the team.
- The team presents the increment resulting from the Sprint to the Stakeholders, which has been previously validated by the Product Owner.
- It is essential to have the software working.
- The objective is to obtain feedback from the customer and the user.
- The Product Owner and the Stakeholders update the Product Backlog for the following Sprint.
- Sets the business strategy.
Duration: maximum 1 hr per week of the Sprint
Participants: Development Team, Scrum Master, Product Owner, Stakeholders (Optional)
Sprint Retrospective
To reflect on what we’ve been working on, identifying obstacles / opportunities / actions to be taken.
- Internal management meeting for the team to analyse the behaviour and collaboration of the members and identify opportunities for improvement.
- To discuss what has worked well, what could have been done better and what can be improved in the next Sprint.
- All members should speak and voice their concerns.
- Aims to identify improvements to the work process that may be put into practice immediately.
- Method: gather information + propose ideas which are developed into an action plan to be evolved as a team.
Duration: maximum 1 hr per week of the Sprint
Participants: Development Team, Scrum Master, Product Owner
D
Definition of Done (DoD)
The Scrum team defines certain criteria that must be complied with in order to consider a Product Backlog Item to be done.
It is agreed between the Product Owner and the Development Team prior to the first interaction and may be progressively improved during the project.
Definition of Ready (DoR)
A series of conditions that a story must comply with to be taken in a Sprint Planning.
It is agreed between the Product Owner and the Development Team prior to the first interaction and may be progressively improved during the project.
Development Team or Scrum Team
Decides HOW to build the product and also builds it. Self-manages, organises and makes its own decisions.
- Decides together with the Product Owner on the scope of the release
- Accepts the Product Backlog Items as “Ready”
- Decides what enters in the Sprint
- Self-organises and works with commitment to achieve the Sprint Goals
- Decides who works on the different Sprint Tasks
- Decides how to build the product
- Delivers product increments in each Sprint
- Highlights the obstacles that block it from achieving the Sprint Goals
- Inspection and adaptation to improve the working approach
- Builds the “Definition of Done“
- Builds the “Definition of Ready“
- Estimates the Product Backlog Items.
- Creates the Sprint Backlog and keeps it updated.
Team size should be between 3 and 9 members.
E
Epic
A higher grouping level than the functional requirements allowing classification of the requirements (User Stories).
Estimate
Estimates of the relative effort required for each User Story.
Different estimation models exist: Planning poker, T-shirt sizing, PERT (Program Evaluation and Review Technique), Wall estimation…
- The team chooses a relevant estimation method.
- A story is defined (invented by the team) and by consensus they decide on its value (reference story), which will be the unit of measurement for the team.
- Affinity estimates based on the reference story to estimate the rest.
All members of the team participate in the estimation with consensus-based estimates. If there is disagreement, the team members will debate and make a further estimate until they reach a consensus.
For example: how much does an apple weigh…. I may have no idea but if I know how much a peach weighs in that case … by affinity I can estimate that it weighs the same. If I’m asked how much a cherry weighs or a pear it would be half, or less… simple, isn’t it?
I
Increment
Sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.
This increment must be ‘Done’, meaning that it complies with the conditions for use and is in accordance with the Definition of Done (DoD) of the Scrum Team.
P
Product Backlog
List of functionalities / requirements we need to accomplish in order to develop our project. The Product Backlog includes all the User Stories we previously described and priorized.
- Contains the requirements to achieve the Goal.
- Acts as an inventory of things to do.
- Transparent and dynamic.
- The Product Owner is responsible for its management.
- The only source of work for the Development Team.
- Contains all the information necessary to preview the planning and presentation of reports.
- Ordered based on:
- ROI (Return On Investment), value, dependencies, risks, …
Product Owner
It is the person who decides WHAT will be built. Define the characteristics of the PRODUCT and PRIORITIZE the Product Backlog.
What ARE his tasks?
- Identify, define and prioritize the needs of the product within the Stakeholders
- Ensures that support and control areas needed to launch the product are met
- Represent the user (Stakeholder) and is the link with the team
- It is the external voice of the team
- Understand and define the business objective and maximize the value of the product
- Quantify the value that the solution brings to the business
- Define and prioritize User Stories
- Validate the deliveries of each Sprint
- Ensures scaling and equipment support
What ARE NOT his tasks?
- DO NOT estimate User Stories
- He is NOT the manager / director of the development (he says WHAT not the HOW)
There will be a Product Owner in each Scrum Team.
Requires: good decision-making and negotiation skills, being an organized person and a keen eye for planning.
S
Scrum
This is a framework for agiledevelopment of software or complex projects.
It has the following pillars:
- Agile Manifesto principles
- The chicken and the pig fable
- Rugby Scrum: a scrum is a typical formation during rugby games in which all the players are linked to contest the ball. It symbolises the essence of these development teams to perfection. The ball isn’t won by the team that has the strongest player but rather those that work best as a team. That is precisely the objective of the Scrum, hence its name.
It’s very easy to understand yet difficult to master and maintain.
Scrum Master
This is a Facilitator, a key role within the Scrum team (also named Development Team).
What does the Scrum Master do?
- Acts as a helpful leader for the SCRUM team.
- Ensures that Scrum has been understood and adopted.
- Eliminates obstacles and guides the team in the application of Scrum practices.
- Facilitates Scrum meetings (ceremonies).
- Ensures the team is multi-functional, self-organised and self-managing.
- Guides the Product Owner with its tasks.
- Protects the Development Team from outside interference.
- Guides and challenges the development team to improve quality and productivity.
- Ensures the team members are motivated.
What doesn’t it do?
- IS NOT a technology guru.
- IS NOT the manager / director of projects (micro-management is its enemy).
Each Scrum Team will have a Scrum Master.
Requires extensive social skills and must be: organised, structured, methodical.
Sprints
The Scrum teams work in time blocks that range between 1 and 4 weeks. These time blocks are always set in the project and may vary among the teams. This “time block” is called Sprint. An Agile project is formed by various Sprints.
E.g. If a project is meant to last 3 months, can be form by 6 blocks of time (of 2 weeks – so our Sprint lasts 2 weeks each) then our project will have 6 Sprints.
During these time blocks a product increment is created which is both usable and potentially deployable in a Productive environment.
Each new Sprint begins immediately after the end of the previous Sprint.
Stakeholder
Any party involved with an interest in the product being built.
Participate in a timely manner in the identification and validation of requirements supporting the Product Owner, they will guide the product definition in a more strategic way.
They will have access to all the information of the product that is being built.
The Product Owner will invite them to the Sprint Review ceremony.
It is essential to identify them and count on them from minute zero.
T
Team agreements
The Scrum teams define their own rules to facilitate the start-up and adequate functioning of the team.
We all have our own experience/culture and in many teams there are even different languages. Clearly defined rules help to reduce conflicts, provide a basis for self-organisation and commitment and facilitate achievement of the goals.
They may be grouped in terms of: respect, participation, ceremonies, transparency, blocks, commitment.
They are defined prior to the first interaction and may be evolved during the project.
U
User Stories
All the User Stories are basically our list of requirements, also known as Items. The group of these Items (or User Stories) are the Product Backlog Items.
The standard template is as follows:
As a (intended user), I want to (intended action), so that (goal/out come of action) + Acceptance Criteria
The most important user stories (prioritised) are defined with the maximum possible detail in a language that is understood by the Requesting Party (User).
It is very good practice to apply certain quality rules, for example:
- Aim to break down a complex requirement into simpler individual requirements (it must be possible to build in a sprint).
- Avoid overlap: each requirement describes a specific aspect.
- Avoid subjectivities and value judgements.
- Don’t use conjunctions (and, or…), negatives or pronouns, as they may lead to contradictions. In such cases, simplify the requirement more.
- Avoid technical terms to the extent possible (it is a user-level document).
We may also have requirements that are operational or related to accounting, reports, forms, coexistence, data or any other type of requirement.
When they are refined by the team they are completed with: the design of the screens, the test cases, the sequence diagram and the supporting architecture.
Reference User Stories
Guide – unit of measurement allowing the team to make estimates.
How is it created?
- We think of a user story that has nothing to do with the product being built and must be able to be understood by anyone: example login, enquiry screen… it must also be possible to build in the time interval of a sprint.
Individually, each person in the team proposes a story and it is decided by consensus. - This story is developed so that it complies with the Definition of Ready (DoR).
- The entire team estimates the effort involved in executing the story, based on all the work that must be done to consider that story as Done (DoD) using the relative estimation model agreed upon by the team.
V
Velocity
The sum of the points of all the work carried out on a sprint.
This measure is usually compared between Sprints to be able to make projections. For example: What scope will we cover in February? Does it look like my next Release could release it inside X Sprint?
Agile teams tend to increase speed as they mature.
Vision
It must transmit the essence of the future product in a concise manner and establish a sharedgoal.
Characteristics:
- Shared and unified
- Extensive and attractive
- Short
- Clear and stable
Sonia Sánchez Sansegundo
Santander Global T&O
Totally convinced and in love with Agile. Positive. Challenge: to help my colleagues to know and experience the Agile so that they enjoy, like me, this experience. Agile Coach
