Get certified - Transform your world of work today



An Agile glossary

16 July 2014


  • Agile is a software development method that supports iterative software development.
  • This process is flexible and customizable, thus gaining popularity over the traditional Waterfall method.
  • This process encourages and inculcates self-coordination and self-organizing traits within the team during the software development.


Burn-down chart
  • The burn-down chart is the best way of showing sprint progress.
  • It covers the status of user stories throughout the duration of a sprint(s).
  • A typical burn-down chart looks like this:
    • If the effort (blue line) is going inline with the red line, then the sprint schedule is on track.
    • If the effort (blue line) is going below the red line, then the sprint schedule is impacted and it's time to take necessary steps.


Change management
  • Agile rollout is a culture change.
  • Organizations need a thorough and well-developed change management strategy to roll out Agile at proper intervals.
  • Here, change management can be viewed in multiple ways: 1) how projects within the organization are executed and 2) how teams have to embrace the change. The first talks about a creative way of delivering projects -- using Agile/Scrum -- with value-added features (by prioritizing user stories) for speed to market. The second talks about change of mind-set and readiness to embrace the change by people within the organization.
  • Needless to say, it's a tough task to get support from teams who were comfortable with Waterfall methods and/or any self-made project management processes.
  • A typical change management plan, discussing goals, objectives, Agile foundations, benefits of Agile, Agile versus Waterfall differences, training, coaching, mentoring, and Agile trial rollouts would be a good start.

Cross-functional teams
  • A typical sprint may have a product owner, ScrumMaster, and team members.
  • These team members can be either BAs, developers, testers, or, sometimes, they may be people coming from peer groups with different functional expertise who will work on the sprints for an ultimate common goal.
  • These team members can be internal (say, from the marketing or architecture teams) or external (such as vendors or IT consultants).
  • Depending on the sprint needs, these team members will be involved in the proper planning to give and receive support in the sprint completion.


Daily stand-ups
  • Daily stand-ups are the meetings that focus on:
    1. What's complete?
    2. What's pending?
    3. Are there any open obstacles that are hindering the progress?
  • Fifteen minutes is a recommended duration for stand-up meetings.
  • However, Agile teams can set up the duration of the meetings based on their sprint needs and schedule.
  • In case any issue requires detailed discussion, the ScrumMaster has to schedule an offline meeting with required attendees (it's a takeaway item).


Earned value
  • Earned value (EV) is an actual measurement of project performance.
  • It calculates the effort/work completed for the dollars spent, as of today, and thus calculates whether the project is under/over budget and/or on/off schedule.
  • This formula is used very commonly in Waterfall projects.
  • Is there a way to calculate EV in Agile projects? Yes, using velocity; see more information under "V."


Failed sprint
  • Can a sprint fail? When is a sprint considered to have failed? When the identified user stories -- during sprint planning -- could not be delivered within the sprint duration.
  • Possible reasons may include additional user stories coming out of identified stories, effort being more than estimated, dependencies identified in the middle of the sprint, resource emergencies, etc.
  • It is recommended not to extend the sprint duration if a sprint is going south; scrapping the sprint and starting a new one with revised scope would be a good solution.
  • Never hold and/or extend the current failure(s).
  • Start every sprint fresh with revised business-valued user stories.

First sprint
  • The first sprint, or Sprint Zero, is the preliminary sprint where the environment set-up or basic sprint activities are worked upon.
  • For example, a typical Sprint Zero may have activities such as understanding the goals and objectives of the project, resource onboard, environment set-up, feasibility study of the project using the Agile framework, etc.
  • Sprint Zero will help the teams test the waters.


  • Agile games play an important role during the project's execution.
  • There are many Agile games invented by Agile enthusiasts to increase team coordination, improve product owner-team relationships, introduce Agile into companies, etc.
  • Core software development companies who implement Agile projects on a full-fledged basis have followed these games for improving overall team productivity.


  • "Hyperproductivity = Fast delivery" is a misconception. In reality, it results in team fatigue.
  • Agile sprints require commitment and support from teams, as the duration is aggressive; on large projects, there may be many sprints that the team has to work on one after the other.
  • However, cautious planning will take the entire team down the road toward success.
  • Many companies tend to load Agile teams with back-to-back sprints with no breaks for fast delivery; that may result in the team reaching a saturation point and resulting in low productivity after a couple of sprints.
  • Better planning should be undertaken to provide proper breaks between the sprints and get teams into a rhythm for successful delivery.


Iterative or incremental software development
  • Iterative or incremental software development is the key aspect of Agile.
  • A product is developed using iterative methods, i.e., continuous repeated cycles and/or incremental development, i.e., developing/delivering the software in logical, independent chunks.
  • This software development helps deliver business value to user stories at a faster pace.
  • Time to market is quick.


Just in time
  • "Just in time" is one of the production strategies of Kanban.
  • This strategy focuses on cutting unnecessary production and delivering what is required.
  • Although it is applicable for manufacturing industries, this strategy can be used in Agile projects too.
  • If you ever have to spend money out of your pocket, remember this mantra: "Just in time and just enough," i.e., you spend only on needs, and you spend cautiously (not over or under).
  • On Agile projects, documenting value-add user stories and prioritizing what is immediately required for business, opting for tailored documentation that is just enough for the delivery, and onboarding only the required number of resources, etc., are some of the just-in-time traits.


  • Kanban means "signboard" or "billboard" in Japanese.
  • It is actually a scheduling system for just-in-time and Lean strategies, which are predominantly used in manufacturing industries.
  • Automotive industries, like Toyota, are big supporters of Kanban, as it reduces waste and emphasizes speed of delivery with its efficient processes.
  • Agile also emphasizes speed of delivery and reduction of waste by creating and maintaining business-value stories and their delivery.
  • In some companies, Agile projects and Kanban go hand in hand; larger Agile projects will have big Kanban boards in the Scrum rooms to track the progress of various sprints.
  • These Kanban boards will provide visual representation of "work in progress" and "complete" status.
  • See this sample:


Life cycle
  • The life cycle of Agile contains various phases.
  • The first phase is creating a product backlog with prioritized user stories.
  • The second phase is creating a sprint backlog, which contains selected user stories for estimation.
  • Sprints will be planned based on the effort estimated, and resources are assigned to work on the sprints.
  • These sprints will be either simultaneous or incremental, depending on the project needs, with fixed duration.
  • As the functionalities are developed, code will be deployed.
  • For every sprint, this life cycle is followed:


MoSCoW technique
  • The MoSCoW technique is used to prioritize the requirements/user stories.
  • This originated in DSDM (Dynamic Software Development Method), which is one of the Agile methods.
  • This technique is very helpful on projects where time is a real constraint and where business believes that they want "everything."

  • Must-have user stories are necessary.
  • Should-have user stories have the next priority.
  • Could-have user stories can wait.
  • Won't-have user stories are not required.
  • This technique helps business understand which functionalities can go first in priority and which can wait; the outcome of this exercise is to have focused delivery for value-add features only.

  • The Agile Manifesto has a set of principles and assurances for all software development projects.
  • It talks about doing the right things in the right way.


Number of sprints
  • In an Agile project, there is no recommended number of sprints.
  • Agile teams can define n number of sprints based on the project needs.


  • Program or project objectives need to be discussed with Agile teams during the kick-off.
  • They help Agile teams understand the end goal and commit to the deliverables.


Product owner (PO)
  • A PO is one of the standard Scrum roles.
  • A PO is responsible for creating the product backlog.
  • A PO can be a business lead, business SME, or sponsor with insights into business, as he/she has to work with team members closely on every sprint.
  • A PO comes with immense business knowledge; he or she is the owner of the product backlog and a key decision maker in prioritizing the user stories for development.
Product backlog
  • A product backlog is a list of functionalities added by business during the project initiation phase.
  • These functionalities are split into logical epics or an independent user stories.
  • These epics or user stories are then prioritized by the PO, along with the ScrumMaster and team members.
  • A product backlog is a living document.
  • Prioritization of user stories may go up and down depending up their value add to the business.
  • A PO, SM, and the team will always review the product backlog before starting the next sprint.


  • Do not quarantine various Agile teams.
  • Agile emphasizes team coordination and mutual helping; the visibility of project progress is crucial.
  • In the case of multiple sprints running at the same time, do not quarantine Agile teams.
  • As much as possible, colocate the teams, as it helps reduce the turnaround in closing any issue; also, increase the visibility of project status through burn-down/Kanban charts.


  • Agile has three key roles: product owner, ScrumMaster, and team member.
  • See "P," "S," and "T" for more about the product owner, ScrumMaster, and team member, respectively.

Release planning
  • Release planning is one of the key activities in the Agile life cycle.
  • As much as teams pick up logical, independent user stories, a detailed plan has to be laid out to understand the overall release of the functionalities by identifying the dependencies to release a potentially shippable product.
  • All sprints may not be ready to go into production right after development and testing.
  • In such cases, release planning will help the team understand when sprints can be released into production and are available for business to use.
  • Sprints can be released incrementally or at one go, depending upon the project needs.
  • Each release may have one or more than one sprint.
  • Depending upon what functionality you are releasing, it is recommended to work with cross-functional teams in release management to schedule and align Agile project releases.

  • Retrospectives are lessons-learned sessions that are conducted by the SM at the end of each sprint and/or the end of multiple sprints.
  • This meeting is held to understand what went well (so that they can repeat it again) and what the opportunities for improvement are.
  • Agile teams strive to excel after each sprint; the team's goal is to learn from the mistakes of the past sprint and plan the next sprint for better delivery.

  • Product reviews are part of the Agile life cycle.
  • Product reviews are organized by the SM for the PO, team, customers, and other stakeholders before the code is released into production.
  • Reviews are like user acceptance tests, where business gets to test/see the demo of the product.
  • If any new user stories crop up during product reviews, they are added to the product backlog for prioritization.


ScrumMaster (SM)
  • The SM is one of the standard Scrum roles.
  • The SM facilitates various planning and execution meetings to help the team perform well.
  • The SM makes sure the team does not have any obstacles during the sprint.
  • The SM is responsible for creating burn-down charts and providing the status of the sprints to appropriate audiences.
  • The SM does not "manage" but "leads" the team (unlike a project manager).
  • In case anything goes wrong during the sprint, it's not the sole responsibility of the SM; the entire team, consisting of PO, SM, and team members, are responsible.
  • The SM is responsible and committed to the Scrum process and makes sure team members understand and follow this process.

  • Scrum is one of the methods under the Agile umbrella.
  • Scrum supports iterative and incremental software development.
  • Most of the time, Agile and Scrum terms are used loosely/interchangeably.
  • The word Scrum is taken from rugby's "scrum" or "scrummage."
  • As in the game, the team's commitment and support are required for sprints to deliver on time in Scrum projects.

  • A sprint is a specific duration during which a set of tasks are completed.
  • A typical recommended sprint lasts two weeks; however, the duration can be decided based on the project.
  • In a sprint, the PO, SM, and team members are involved to perform identified tasks throughout until its completion.
  • Daily stand-up meetings are held during the sprint to understand progress.
  • In the case of any show-stoppers, the PO and SM help the team members.


  • Timeboxing is allocating a fixed time for a specific task or tasks.
  • A sprint is a timeboxed activity during which tasks are estimated and considered for delivery.
  • Once the duration of the sprint is set, it has to be met.
  • Teams should not extend the sprint duration in case of any delays; instead, they have to drop the sprint and start a new one.
  • Timeboxing allows for proper planning and prioritization.
  • Timeboxing is a unique technique used in all Agile methods.

  • There are many Agile tools on the market that help track and manage projects well.
  • These tools may be free or for purchase.
  • These tools will come with inbuilt features such as burn-down charts, release plans, a product backlog, backlog management, sprint planning, sprint tracking, etc.
  • Users can create various colorful visual graphs or reports any time, to understand and measure the sprint/project status.
  • Rally and Version 1 are examples of commercial tools with high user ratings.

Team member
  • A team member is a key role in Scrum (along with product owner and ScrumMaster).
  • A team member can be a BA or developer or tester and/or any peer-group cross-functional expert.
  • Team members are involved in estimating user stories, discussing prioritization, and actually implementing the selected stories.
  • In Agile, activities are done as a team; key decisions are made by the PO, SM, and team members as a group.
  • Each team member comes on board with a specific skill set that is required to deliver the shippable product within the sprint duration.
  • The SM works with the PO to select the resources with the right skill sets during Sprint Zero.
  • Team members should understand the project's goal.
  • Team members should deliver the product in line with the agreed-upon user stories.
  • Team members should be self-organized and accountable for their deliverables.
  • The commitment of team members is key for any sprint to begin; they should speak up in case of any challenges that may hinder their individual or collective deliverables.
  • Team members have to exert lots of coordination during the sprints. As they work on more sprints, they get into a rhythm that helps measure the velocity of sprints.


User story
  • A user story is a business requirement.
  • It is a feature or a functionality that has business value and helps run the business.
  • User stories are given by the product owner.
  • Typically, a user story has to be a logical and independent item to consider bringing into a sprint.
  • A user story should contain "what," "why," and "who" components, i.e., what the user needs, why the user needs it, and who wants it.
  • A typical user story example: As a customer representative, I want to see policy details (such as first name, last name, policy number) upon clicking the policy number so that I can better manage the policy.


  • Velocity is the method of calculating the number of units consistently done by the Scrum team per sprint.
  • Velocity considers units of work, not the actual effort, for calculation.
  • The velocity of each team differs, as the estimation of effort by the teams varies.
  • Velocity can be calculated once the team gets into a rhythm.
  • Velocity is measured purely based on prior sprints' completion, and future interpretations are made for forecasting purposes only.
  • It helps to understand how much work the team can complete over a period of time, approximately.
  • Velocity helps us gain an understanding of the consistent number of units that a Scrum team can deliver over time.
  • Sample velocity chart:


  • Waterfall is a traditional project management method.
  • It's a sequentially phased process.
  • Teams will move from one phase to another only after the previous phase's completion; there's a phase-gate/phase-exit to clear before entering into the next phase.
  • The life cycle of Waterfall includes the analysis, design, development, testing, and release phases.
  • All requirements will be determined at the beginning of the project.
  • Design, development, and testing will be carried out based on the initially agreed-upon requirements.
  • Projects may range anywhere from 1 to 1½  years.
  • There is less flexibility in changing the requirements or stalling the activities, as the team is working on the requirements that were documented months ago.
  • In the case of new requirements, a change request (CR) process needs to be initiated; any new requirement that was not identified at the beginning of the project is treated as scope creep.


XP Programming
  • Extreme Programming (XP) is one of the software development processes under the Agile umbrella.
  • It emphasizes iterative and incremental software development.
  • Like any Agile method, this process focuses on business value-driven features -- delivery, team collaboration, and flexible and productive delivery.


  • In the investment world, "yield" means income or return on investment; in road transport it means "slow down."
  • Agile helps run the business by prioritizing business-value features and their faster delivery, thus paving a way to yield.
  • When projects fail in the middle or at the end of, say, two years' duration, organizations lose lots of money; technically, the money is irrecoverable and the effort spent by teams and the money that went into building the solution are of no use. To avoid this kind of situation, every organization/team has the right to know what best works for their projects.
  • Agile helps teams make the right decisions in identifying which business-value requirements can be taken up first.
  • Also, if the organization is in a dilemma about which method to follow for project solutions, then Agile provides an opportunity to do a couple of sprints at the beginning to understand the benefits; Agile yield helps teams slow down and think creatively to deliver solutions faster.



  • Agile means a mind-set shift and a culture change.
  • Agile teams with a great desire to learn creative solutions and deliver will be successful.
  • Agile team members should have zeal to understand, commit to, and support the delivery.
  • "Inspect, adapt, and deliver" should become second nature for the teams as they get into sprint rhythms; of course, this will be achieved through management involvement and team collaboration and commitment.

Note: Images courtesy: Internet

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3 (5 ratings)


Vinay Barigidad, CSM, 7/16/2014 2:44:46 AM
A nice alphabetical summary. A good read for anyone in learning "agile in a 30 minutes".
Krishnakumar Chinnappachari, CSD,CSM,CSPO, 7/16/2014 5:19:27 AM
Yes, agree with Vinay. Truly nice compilation on Agile Glossary
Thanigaimalai Thangavel, CSM, 7/16/2014 6:03:08 AM
Short and Help to step in quick reference.
Suresh Konduru, CSP,CSM,CSPO, 7/19/2014 4:03:21 PM
Good glossary. Thanks for sharing.
Rohit Ratan Mani, CSP,CSM, 7/22/2014 8:00:04 AM
Great summary Savvy, thanks for putting this up.
Raju Joshi, CSM, 8/22/2014 1:22:18 AM
Thanks a lot for such a wonderful summary. Very useful for all....
SAVVY KATHAM, CSP,CSM, 2/4/2015 8:24:19 AM
Thank you all for the comments, appreciate it.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up