Agile Terminologies refer to the specific language or vocabulary used in Agile software development methodology, including terms such as Scrum, Sprint, Backlog, User Story, Product Owner, and Sprint Review, among others. These terms have specific meanings and are used to facilitate communication and collaboration within Agile teams.
Following are some important Agile Terminologies
Agile:
Agile is a methodology that emphasizes iterative and flexible approaches to delivering. It values the ability to quickly respond to change and incorporates feedback from users throughout the development process. Agile is a mindset where the team adjust based on the situations as they arise. The team collaborate to solve problems. developed the product in small iterations/Increments and then got customer feedback.
For example, a development team might use Agile to build a new website for an online retailer. They would work on a series of sprints, delivering new features and improvements with each iteration. The product owner might prioritize user stories based on customer feedback and changing business needs, with the development team adapting their plans and work accordingly. Through this iterative process, the team can deliver a high-quality product that meets the needs of the users and the business.
Agile Manifesto
The Agile Manifesto is a guiding document created by a group of 17 software developers in 2001, known as Agile Alliance. It outlines the values and principles of agile software development, emphasizing customer collaboration, flexibility, and responsiveness to change. The manifesto
- prioritizes individuals and interactions over processes and tools,
- working software over comprehensive documentation,
- customer collaboration over contract negotiation, and
- responding to change over following a plan
Agile guiding Principles
The Agile Guiding Principles are based on the core values of the Agile Manifesto and are designed to address the challenges often encountered in traditional project management approaches. These principles guide agile teams in achieving success by fostering collaboration, flexibility, and continuous improvement
Predictive, Adaptive and Hybrid Approaches
Predictive, Adaptive, and Hybrid approaches are the three primary software development strategies.
- In Predictive strategy, / Plan Driven
a precise plan is created and adhered to throughout the duration of the project. The timetable, budget, and deliverables are all specified and determined from the beginning of the project. This method is ideal for projects with well-defined needs and stable environments. - The Adaptive strategy, / Change based
often known as Agile, places emphasis on adaptability and flexibility. On the basis of feedback from stakeholders and changes in the development environment, requirements and project plans are continuously revised and reevaluated. This strategy is ideal for projects with quickly changing requirements and a high level of uncertainty. - The hybrid technique, / Change basedb
as its name implies, contains features of both the predictive and adaptive approaches. It entails drafting a high-level strategy at the beginning of the project while allowing for flexibility and modification as the project develops. This strategy is ideal for projects requiring a balance of predictability and flexibility.
Agile and Waterfall methodologies
Waterfall and Agile are two different project management methodologies with their own strengths and weaknesses. Waterfall is best suited for projects with well-defined requirements, while Agile is best suited for projects with changing or unclear requirements. Waterfall is a sequential approach, while Agile is an iterative approach that emphasizes collaboration and flexibility.
—————————————————–
Agile Frameworks
Scrum:
Scrum is a framework for agile software development that is based on iterative and incremental development. It emphasizes collaboration, flexibility, and continuous improvement. Scrum provides a structured approach to managing and completing work in a fast-paced and dynamic environment. Scrum includes roles such as Product Owner, Scrum Master, and Development Team, and also includes ceremonies such as Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
An example of Scrum is a framework used to manage a software development project, where the team works in short sprints and delivers working software at the end of each sprint.
Kanban – Visualizing workflows
Kanban is a visual representation of the state of work in process. It helps to control how much work in process is permitted at one time, which can help to reduce bottlenecks and ensure the team is working efficiently. Kanban is less time-based and is focused instead on managing the volume of work in process (WIP)
An example of a Kanban board is a physical or digital board that displays the status of tasks or stories, such as “to do,” “in progress,” and “done.”
Lean –
Lean is a set of practices and principles used to maximize customer value with the same or fewer resources by eliminating waste from business processes. This can include reducing wait times, optimizing processes, and minimizing unnecessary work.
An example of lean methodology is identifying and removing waste in a manufacturing process to increase efficiency and reduce costs.
General Overview of Other Agile Frameworks
—————————————————–
Initiation of the Agile Project
Product Vision
It’s a concise statement that captures the long-term goal and aspirational future state of your product. It’s the cornerstone of your product strategy. It informs your roadmap, which informs your daily decisions as a product team.
Product Value
- The “What” and “Why” of Your Product: It encompasses the overall benefit your product provides to users, solving their problems and addressing their needs. This value can be tangible (e.g., increased efficiency) or intangible (e.g., improved user experience).
- Customer-Centric: Understanding customer needs and pain points is crucial in determining what constitutes value for them.
- Multifaceted: Product value considers not just user satisfaction but also business goals like revenue generation or market share increase.
Agile Project Charter
An Agile project charter is a document that serves as a roadmap for an Agile project. It’s created at the beginning of a project and is a high-level guide that outlines the project’s goals, objectives, and deliverables
“Agile projects leverage the Lean startup model to develop and test a hypothesis and then stop, pivot, or persevere,” explains Alan Zucker, Founding Principal of Project Management Essentials. “Projects stop if the team realizes this is not a viable product or there is not a market for it. We should cut our losses and move on. We pivot when we find a nugget worth pursuing, but it requires changing direction. We persevere when the hypothesis is validated.”
Creating an Agile project charter ensures that all team members understand the objectives, output, timeline, and budget of a project. By using an Agile project charter, project managers can more easily identify and mitigate risks and track progress against goals.
Release and Release Planning
A release refers to the delivery of a set of functionalities or features to the end user. This could be a new version of an app, a software update, or the launch of a new product entirely.
Release planning is the process of defining, planning, and coordinating the activities involved in delivering a release
Scope/Requirements
Product Road Map
A product roadmap is a high-level action plan that outlines the vision, direction, and progress of a product over time. It’s a strategic plan that defines a goal and includes the steps needed to reach it.
Objectives of Product Roadmap
- Describe the vision and strategy
- Provide a guiding document for executing the strategy
- Get internal stakeholders in alignment
- Facilitate discussion of options and scenario planning
- Help communicate with external stakeholders, including customers
Epic –
Epic are user stories with a scope so large it is difficult to complete them in a single iteration or to accurately estimate the level of effort required. These stories are usually broken down into smaller, more manageable user stories for development
An example of an epic story is a feature that requires multiple sprints to complete, such as integrating a payment gateway into an e-commerce website.
Story Points:
Story Points are a unitless measure of the relative size and complexity of a user story or task. They are used to estimate the effort required to complete a piece of work and to track progress during the Sprint. Story Points are often based on the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.), which reflects the idea that it becomes more difficult to estimate larger and more complex tasks.
For example, a development team is tasked with creating a new feature for a software application. They estimate the feature to be 8 story points, based on the level of complexity and effort required to complete the work.
User Story:
A user story for a software application may describe a specific feature or functionality from the perspective of the user. For example, “As a user, I want to be able to search for products by category, so that I can find the products I need more easily.” This user story provides a high-level description of a requirement and allows the development team to estimate the level of effort needed to implement it.
User stories are a way of capturing requirements in Agile development. They are short, simple descriptions of a feature or functionality from the perspective of the user. User stories are meant to be a placeholder for a conversation between the product owner and the development team. They are typically written in a specific format, such as “As a [user], I want to [action] so that [goal]”. The user story should provide enough information for the development team to understand the feature and provide an estimate of the effort required to implement it. User stories are often prioritized by the product owner and added to the product backlog for future development.
Definition of Ready
It helps ensure that user stories or tasks are well-defined and ready for development before the development team begins work on them. It is a set of criteria that must be met before a user story or task is considered ready for development.
A simpler example would be:
- User Story: As a user, I want to be able to edit my profile information.
- The user story has a clear description of the functionality.
- The user story has been estimated and prioritized in the product backlog.
- The user story has acceptance criteria that define what is considered a successful outcome, including the ability to edit user profile fields such as name, email, and profile picture.
- The user story has been reviewed and approved by the product owner and stakeholders.
Definition of Done –
The definition of done is a set of criteria that needs to be met for work to be accepted as complete. This can include items such as passing tests, completing documentation, and meeting the acceptance criteria.
An example of a definition of done is a checklist that includes criteria such as code reviews, automated tests, and user acceptance testing that must be met before work is considered complete.
Minimum Viable Product –
A minimum viable product is a product with just enough features to test and gather information about the product and its continued development. This allows the team to validate their assumptions about the product and make informed decisions about future development.
In example of an MVP is a new software product that has only basic features and is released to a small group of early adopters to gather feedback before additional features are added.
—————————————————–
Agile Team/Roles
Product Owner:
The Product Owner is responsible for ensuring that the product being developed meets the business needs and delivers value to the customers. They work closely with the development team and other stakeholders to understand the product vision, requirements, and priorities, thus ensuring shared understanding of the value. The Product Owner is responsible for managing the product backlog, which includes prioritizing and refining user stories and making sure that the team is working on the most valuable items. While working with stakeholders, he manages their expectations and make sure the product delivers the requirements
An example of a product owner is a business analyst who represents the customer’s needs and priorities and works with the development team to deliver a high-quality product. H
Scrum Master:
The Scrum Master is responsible for ensuring that the Scrum framework is followed properly and that the team can work effectively and efficiently. They coach the team on Scrum principles and practices, facilitate meetings such as Daily Scrum, Sprint Planning, Sprint Review, and Retrospective, and remove any impediments that are preventing the team from making progress.
An example of a Scrum Master is a facilitator who ensures the Scrum process is followed, impediments are removed, and the team stays focused on their goals.
Scrum Team:
The Scrum Team is a self-organizing, cross-functional group responsible for delivering the product. The team includes developers, designers, testers, and any other roles needed to complete the work. The Scrum Team works together to plan, develop, and deliver high-quality products that meet the customer’s needs. They do;
- Build the product incrementally
- Update Information Radiators
- Self Organzie the work
- Hold retrospective
Cross-Functional Team –
A cross-functional team is a team made up of members with all of the functional skills needed to complete a project. This can include members with skills in development, design, project management, testing, and more.
An example of a cross-functional team is a team composed of developers, designers, and business analysts, each with unique skills and knowledge to deliver a project.
—————————————————–
Sprint/Iterations:
A Sprint is a fixed time-boxed period (usually 1-4 weeks) during which the Scrum Team works to deliver a potentially shippable product increment. The work to be done is defined in the Sprint Backlog, which is created during the Sprint Planning meeting. At the end of the Sprint, the Scrum Team delivers a working product increment that is reviewed and evaluated during the Sprint Review meeting.
Agile Ceremonies
Sprint Planning:
Sprint Planning is a two-part meeting that happens at the beginning of every Sprint. In the first part, the Product Owner and the Scrum Team collaborate to define the Sprint Goal and identify the user stories to be completed in the Sprint. In the second part, the Development Team creates a plan to complete the selected user stories and identifies the tasks required to do so.
Agile Planning follows adaptive planning, which is a flexible project management technique that promotes adaptability to changing requirements and client expectations. Consisting of continuous iteration, regular reevaluation, and as-needed plan modifications..
Daily Scrum/Daily Standup –
A daily scrum or daily standup is a meeting that starts on time in the same location every day. The purpose of this meeting is to ensure team members are aligned on what story they are working on, what impediments are blocking tasks, and what the next steps are when the current story is complete. This meeting is usually led by the scrum master.
An example of a daily scrum is a quick 15-minute meeting held each morning where the team discusses their progress, what they plan to do next, and any impediments they may be facing.
Sprint Review:
Sprint Review is a meeting that happens at the end of every Sprint, during which the Scrum Team presents the work that was completed during the Sprint. This includes a demonstration of the working product increment and a review of the Sprint Goal. The team and stakeholders collaborate to discuss the product and provide feedback, which is used to inform the next Sprint.
Retrospective:
A retrospective is a meeting that happens at the end of every development iteration (Sprint) where the team reviews the work that was completed, the processes and practices that were used, and identifies areas for improvement. This is an opportunity for the team to reflect on what went well, what didn’t go so well, and what could be done differently in the next iteration to increase efficiency and productivity.
Backlog Grooming/Backlog Refinement –
Backlog grooming is the process of adding or reprioritizing user stories on the backlog. This process ensures that the backlog is up to date and that the team is working on the most important items first. Backlog grooming is usually done by the product owner and the team.
An example of backlog grooming is when the development team reviews and refines the items in the backlog to ensure they are prioritized correctly and have the right level of detail.
—————————————————–
Backlog/Product Backlog –
A backlog is a unit of work that is typically listed on the project backlog as a user story or a task. The backlog represents the work that needs to be done by the team to complete the project. The backlog is usually prioritized by the product owner and is constantly changing as new items are added or completed.
An example of a backlog is a list of features, user stories, and bugs that need to be addressed in a project.
Impediment –
An impediment is anything that keeps a team member from getting work done as efficiently as possible. This can include technical issues, communication breakdowns, or external factors outside of the team’s control.
An example of an impediment is a team member who is blocked because they do not have access to the required resources or information to complete their work.
Bottleneck –
A bottleneck is a congestion in a system that happens when workload arrives more quickly than can be handled at a given point. In a development team, a bottleneck can occur when one team member is unable to complete their work, which can slow down the entire team. It is important to identify and address bottlenecks as quickly as possible to ensure the team can continue to work efficiently.
An example of a bottleneck is a slow database that slows down the entire application because it cannot process queries fast enough.
Information Radiotors
“Information radiator” is the generic term for any of a number of handwritten, drawn, printed or electronic displays which a team places in a highly visible location, so that all team members as well as passers-by can see the latest information at a glance: count of automated tests, velocity, incident reports, continuous integration status, and so on.
What is an Information Radiator? | Agile Alliance
Burndown Chart –
A burndown chart is a visual tool for displaying and measuring progress. It shows the remaining work for a given sprint or project over time, allowing the team to track progress and adjust their approach as necessary.
An example of a burndown chart is a visual representation of the progress of a sprint, where the team tracks the remaining work and adjusts their plan to achieve their goals.
Throughput and Throughput Chart
Throughput is the rate at which work is completed, often measured in units per unit of time (e.g., stories completed per iteration, features delivered per month). For example, as work is visualized in cards, throughput is measured based on how many Kanban cards were finished in a given period (weekly, monthly, etc.)
Throughput Chart is a visual representation that displays throughput over time. It helps identify trends and monitor team performance.
Velocity
Velocity is a metric used in Agile software development to measure the amount of work a team can complete within a sprint. It is the total amount of effort completed by the team in a sprint, typically measured in story points or hours. Velocity is an important tool for planning and forecasting, as it helps the team estimate how much work they can complete in future sprints and how long it will take to complete the entire project.
For example, let’s say a development team has completed three sprints, during which they completed 20 story points, 25 story points, and 30 story points, respectively. Their average velocity over the last three sprints would be (20 + 25 + 30) / 3 = 25 story points per sprint. Based on this velocity, the team can estimate that they will be able to complete approximately 25 story points in each future sprint.
Burndown rate
Burndown rate is a metric used in Agile software development to measure the progress of a team towards completing the work in a sprint. It represents the amount of work remaining in the sprint backlog over time and provides a visual representation of the team’s progress towards the sprint goal.
For example, let’s say a development team has a sprint backlog with 100 story points at the beginning of a two-week sprint. On day one, the team completes 10 story points, reducing the remaining work to 90 story points. On day two, they complete another 15 story points, reducing the remaining work to 75 story points. The burndown rate for the first two days of the sprint would be (10 + 15) / 2 = 12.5 story points per day.
Acceptance Testing –
This is a formal testing process used to determine whether or not a system meets its acceptance criteria. The acceptance criteria are usually a set of predefined criteria that the system must meet in order to be accepted as complete. Acceptance testing is usually done by the customer or end-user to ensure that the system meets their requirements.
An example of acceptance testing is a customer or end-user testing a software application to ensure it meets their requirements and works as expected.
Stakeholder:
Stakeholders can include customers, users, executives, investors, regulators, or any other party that has an interest in the outcome of the team’s work. Their involvement can vary from simply receiving updates to actively participating in the development process. The team needs to identify and engage with stakeholders early on to ensure that their needs are considered and incorporated into the project.
In a software development project, stakeholders may include the company’s executives, customers, investors, regulatory bodies, and others who have a vested interest in the outcome of the project.
Task Board:
A task board is a physical or digital board that displays the status of work items. It is typically divided into columns labelled “To Do”, “In Progress”, and “Done”. The board serves as a visual aid for team members to track the progress of tasks, identify bottlenecks, and ensure that everyone is aware of the current status of work items. Task boards are a key component of many Agile methodologies, including Scrum and Kanban.
A task board can be used to track the progress of a project. For example, a software development team may use a task board with columns labelled “to do”, “in progress”, and “done” to visualize the status of each task and ensure that everyone is aware of the team’s progress.
Summary
The terms listed describe various concepts and practices in agile software development. These include acceptance testing, backlog grooming, burndown charts, cross-functional teams, daily scrum meetings, the definition of done, Kanban, lean practices, minimum viable products, the product owner, retrospectives, sprints, sprint planning and review meetings, story points, stakeholders, task boards, and user stories. These concepts are used to help teams work together efficiently and deliver high-quality products that meet customer needs.
Further Reading
Project Management Terms and Concepts – PMP/CAPM – Mudassir Iqbal
2 thoughts to “Agile Terminologies”
Pingback: Story Map, User Story Mapping - Mudassir Iqbal
Pingback: Navigate Project with Agile: A Flowchart for Streamlined Delivery - Mudassir Iqbal