16 September 2021

Agile frameworks and terminology

Acceptance criteria

  • The acceptance criteria doesn’t be too vague (remember the T of INVEST for defining good User Stories) and cannot be easily tested. [The Art of Agile Development. James Shore.]
    • Acceptance criteria is typically defined in tandem with User Story definition during release planning; however, acceptance criteria can also be defined during iteration planning once a story has been picked for the iteration.
    • The one steadfast rule is that acceptance criteria must be defined before development begins.
    • Like agile planning, the definition of acceptance criteria is constantly evolving as the conversation with the Product Owner matures.
    • [The Art of Agile Development. James Shore.]
  • During release planning, acceptance criteria are typically recorded on the backs of User Story cards.
    • Agile team testers will use this acceptance criteria in their verification tests.
    • [The Art of Agile Development. James Shore.]
  • Acceptance test criteria should be written at the last Responsible Moment while Velocity, Product Backlog and release length are essential input for release planning.

Adaptive

  • Frequently responding to changes and learning’s on a project by changing the plan, priorities, and/or approach.
    • Agilists believe changes are good!

Agile failures

  • The top 12 causes of agile failure (failure modes) according to Aaron Sanders :
    • 1. A checkbook commitment doesn’t automatically cause organizational change or support.
    • 2. Culture doesn’t support change.
    • 3. Culture does not have retrospectives or performs them poorly.
    • 4. Standards and quality are lost in a race to project closing.
    • 5. Lack of collaboration in planning.
    • 6. None or too many Product Owners.
    • 7. Poor project leadership or scrum master that doesn’t place trust in the team and allow it to be self-organizing and self-disciplined.
    • 8. No on-site agile promoter or coach.
    • 9. Lack of a well built, high-performance team.
    • 10. Accrued technical debt if strict testing standards are not upheld.
    • 11. Culture maintains traditional performance appraisals where individuals are honored and the team aspect is lost.
    • 12. Reversion to the traditional or ‘old-way’ of doing business occurs because change is hard.
    • [Coaching Agile Teams. Lyssa Adkins.]

Agile frameworks and methods

  • Agile methods offer several benefits including faster time to market, more business value and improved stakeholder satisfaction.
  • For planning, agile does not recommend heavy upfront planning. Instead, it recommends an initial high-level plan which is re-visited on several occasions throughout the project.
  • Agile methods work well where there is uncertainty in the environment and the results are driven by people rather than process.
  • Heavy-weight methods canvass formality and discipline in order to work the intricacies of the project.
  • In opposition, agile methods favor creativity, improvisation, and nimbleness to negotiate with project hazards.
  • In addition, agile methods welcome change and alternately adapt to the new conditions. Heavy methods are more pessimistic at handling change and try to get all things worked out in the first instance.

Agile frameworks and terminology

  • Common frameworks or methodologies used within agile include: Scrum, eXtreme Programming (XP), lean software development (LSD), crystal, feature driven development (FDD), dynamic systems development method (DSDM), agile unified process (AUP). [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • Agile methods offer several benefits including faster time to market, more business value and improved stakeholder satisfaction.
      • For planning, agile does not recommend heavy upfront planning.
      • Instead, it recommends an initial high-level plan which is re-visited on several occasions throughout the project.
    • Agile methods work well where there is uncertainty in the environment and the results are driven by people rather than process.
      • Heavy-weight methods canvass formality and discipline in order to work the intricacies of the project.
      • In opposition, agile methods favor creativity, improvisation, and nimbleness to negotiate with project hazards.
      • In addition, agile methods welcome change and alternately adapt to the new conditions.
      • Heavy methods are more pessimistic at handling change and try to get all things worked out in the first instance.

Agile Methods

  • A set of development methodologies characterized by being iterative, adaptive to changes and learning, value driven, low ceremony, and encouraging empowered teams.

Asset

  • An asset is defined as a potential future economic benefit that the firm controls based on past transactions.

Acceptance Test Driven Development (ATDD)

Big Design Up Fron (BDUF)

  • Big Design Up Front is a condescending term given to large efforts invested early in the project to define requirements or design before building some functionality and getting feedback from the user community.

Brainstorming techniques

  • Brainstorming is a group activity held for the purpose of generating new ideas.
    • The idea is that through collaboration, a team can generate more potentially valuable ideas than an individual, while at the same time forming a positive bonding experience for the team. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
    • A successful brainstorming event should strive to consider the following points :
      • Host the meeting in a neutral and comfortable environment
      • Have an engaging and experienced facilitator lead the event
      • Send participants an overview, with goals, schedule, and what ground rules, beforehand
      • Have a multi-disciplinary/diverse team to get a broader perspective – Delay any criticism that may stifle idea generation.
      • [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Burn-Down Graph or Burn-Down Chart

  • a project reporting trend graph popular in Scrum used to show the progressive reduction in features or estimated work remaining on the project.
  • Burn-Down Chart

Burn Up Graph or Burn-Up Chart

  • a project reporting trend graph that shows the total number of stories (or features) delivered to date on the project.
  • Burn-Up Chart

Business case development

  • Business case development is an important initial step in agile project management.
  • The business case is a concise document that outlines the project’s vision, goals, strategies for achieving goals, milestones, required investment and expected return/payback.
  • A business case articulates the why and how a project will deliver value to a customer.
  • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Capitalization

  • Capitalization is a record of an expenditure as an asset rather than to treat it as an expense of the current period.

CAPM

  • Certified Associate in Project Management, a designation from the PMI given to project managers who have passed the CAPM exam which is easier and less demanding than the PMP exam.

Caves and common

  • The XP phrase ‘caves and common’ refers to the creation of two zones for team members.
  • The common area is a public space where osmotic communication and collaboration are largely at play.
  • The caves is a private space is reserved for private tasks that require an isolated and quiet environment.
  • For the common area to work well, each team member should be working on one and the same project.
  • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Compliance (organization)

Compliance

  • Compliance is the act of being in alignment with guidelines, regulations and/or legislation.
  • Compliance with a company’s code of ethics and professional conduct is standard practice in agile. [PMI Agile Community of Practice Community Charter. Project Management Institute.]
  • Regulatory compliance : although in agile project management, it is generally practiced to generate minimal documentation to support the project, some specific documents, like those required by regulatory bodies need to be created to comply with local and federal law. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]


Continuous improvement

  • Agile project management places strong emphasis on ‘continuous improvement.’ Continuous improvement processes are built into the agile methodology, from customers providing feedback after each iteration to the team reserving time to reflect on its performance through retrospectives after each iteration. Ongoing unit and integration testing and keeping up with technological/industry developments also play a part in the continuous improvement process. Continuous improvement is also a key principle in the lean methodology, where a focus of removing waste from the value stream is held. [The Art of Agile Development. James Shore.]

Continuous Integration

  • the process of building and testing the system upon the check-in of any code.
  • Examples of continuous integration tools include: Team City and Cruise Control
  • Continuous Integration (CI)

Control limits for Agile projects

  • Control limits – those which set an objective range to indicate whether a process is controlled or stabilized or defect free (e.g., within three sigmas of the mean) – may be used in an agile project. Generally, a control limit of three-sigma (s) is used on a Shewhart control chart.
  • A sigma refers to one standard deviation. So three sigmas indicates a limit three standard deviations away from the mean in both the positive and negative direction.
  • This applies to normal data, where a normal distribution curve has been obtained.
  • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Complex Adaptive System (CAS)

  • A complex adaptive system, or CAS, is a system composed of interacting, adaptive agents or components.
  • The term is used in agile to remind practitioners that the development of a product is adaptive in that previous interactions, events, decisions influence future behavior.
  • The term chaordic (a made up word blending chaotic and order) is sometimes used when describing CASs.
  • Literature points to three key characteristics of chaordic projects: alignment and cooperation, emergence and self-organization, and learning and adaptation.
  • [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Cost Performance Index (CPI)

  • Cost Performance Index is a measure of project progress from a cost perspective.
  • Agile projects can obtain the same metric by dividing the Planned Costs to date by the Actual Costs to date.

Cost Variance (CV)

  • Cost Variance is a measure of how much under or over budget we are.
  • Agile projects calculate this the same way as traditional projects: by deducting the amount actually spent from the amount planned to be spent by now. (negative numbers mean you are over budget)

Critical Path

  • In traditional project management, it is the longest path through the network of project tasks and dependencies.
    • In theory it defines the shorted time that the project can be completed in.
    • Its accuracy is driven by the quality of the task estimates which early in a software project could be very low.

Cumulative Flow Diagram (CFD)

  • A project reporting area graph that shows work to do, work in progress, and done. Burn graphs and CFDs can replace Gantt charts to track progress
  • Agile projects can get the same information by tracking the features delivered
  • Cumulative Flow Diagrams (CFD)

Customer valued prioritization

  • Customer-value prioritization is a method for relative prioritization of product features based on customer-value for ordering the product backlog.
    • When ordering the Product Backlog, it is also important to consider other aspects (e.g., associated risk, dependencies, etc.,) of features. [The Art of Agile Development. James Shore.]

Daily stand-up meeting

  • A Daily stand-up meeting (or simply « stand-up ») is a meeting with attendees typically standing.
  • The discomfort of standing for long periods is intended to keep the meetings short.
  • Some software development methodologies envisage daily team-meetings to provide status updates to team members.
  • The « semi-real-time » status allows participants to know about potential challenges as well as to coordinate efforts to resolve difficult and/or time-consuming issues.
  • The stand-up has particular value in Agile software development processes.
  • Scrum-style daily stand-ups involve asking and answering three questions.
  • Though it may not be practical to limit all discussion to these three questions, the goal is to stick as closely as possible to these questions :
  • What did I accomplish yesterday?
  • What will I do today?
  • What obstacles are impeding my progress?
  • Whereas Kanban-style daily stand-ups focus more on :
  • What obstacles are impeding my progress?
  • (looking at the board from right to left) What has progressed?
  • The meeting usually takes place at the same time and place every working day.
  • All team members are encouraged to attend, but the meetings are not postponed if some of the team members are not present.
  • One of the crucial features is that the meeting is intended as a communication vehicle for team members and not as a status update to management or to other stakeholders.
  • Although it is sometimes referred to as a type of status meeting, the structure of the meeting is meant to promote follow-up conversation, as well as to identify issues before they become too problematic.
  • The practice also promotes closer working relationships in its frequency, need for follow-up conversations and short structure, which in turn result in a higher rate of knowledge transfer – a much more active intention than the typical status meeting.
  • Team members take turns speaking, sometimes passing along a token to indicate the current person allowed to speak.
  • Each member talks about progress since the last stand-up, the anticipated work until the next stand-up and any impediments, taking the opportunity to ask for help.
  • Team members may sometimes ask for short clarifications and make brief statements, such as « Let’s talk about this more after the meeting », but the stand-up does not usually consist of full-fledged discussions.

Dynamic Systems Development Method (DSDM)

  • Dynamic Systems Development Method is an agile method created by a consortium of representatives that promotes ideas such as agile suitability filters and agile contracts.

Earned Value (EV)

  • Earned Value is the value of the work completed to date. .

Earned Value Analysis (EVA)

  • Earned Value Analysis is he process of measuring project performance against the performance defined in a baselined plan.
    • For Agilists an issue is the accuracy of the baselined plan.
    • If that was flawed due to a poor understanding of the true requirements (common for SW) then why track progress against this faulty map.

Earned Value Management (EVM)

  • EVM or earned value management is a management technique used to evaluate project performance with respect to cost and schedule. [Agile Estimating and Planning. Mike Cohn.]

Elaboration

  • The PMBOK’s term for acknowledging that details will likely emerge as the project progresses and perhaps the plan will need amending.
  • However, it assumes that the differences will be small and easily accommodated into the plan.
  • Agile teams can use this concept to introduce more radical adaptation ideas.

Escaped defects

  • An escaped defect is a software defect that is not found by the development or testing team and later found by an end-user. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Facilitation methods

  • As a project leader or scrum master, effective facilitation methods are critical for building a high-performance and motivated team.
  • Facilitation of meetings, discussions, demonstrations, etc., is a constant on an agile project.
  • Some general facilitation methods include: using a small number of people for brainstorming events; hosting events in a non-threatening/comfortable environment; having an agenda that is shared with the group ahead of time; using open-ended questions instead of closed-ended questions; including a diverse representation to gain a broader perspective of the topic.
  • [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Feature Driven Development (FDD)

  • Feature Driven Development is an agile method popularized by Jeff De Luca and others that values some upfront architecture and works well for larger projects.

Feature

  • A description of a business understandable and business valued piece of functionality.
  • The unit for prioritization, planning, estimation, and reporting.
  • Some agile methods use the term Story, or Prioritized requirement.

Gantt Chart

  • Horizontal bar graph based depiction of project task durations and dependencies.
  • Thought by Agilists to be OK at a high level, but detached from reality for modeling detailed technical tasks.

Governance

  • Highsmith defines agile project governance as « making decisions in an uncertain environment. » [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Horizontal-market software

  • Horizontal-market software includes solutions for many organizations in many industries (e.g., word processing software). [The Art of Agile Development. James Shore.]

IKIWISI

  • IKIWISI is an acronym, it means I’ll Know It When I See It
    • a mnemonic that described the need to see working software before being able to fully appreciate it’s fit for purpose and articulate the true business requirements.

Incremental delivery

  • A cornerstone of Agile development is ‘incremental delivery.’
  • Incremental delivery is the frequent delivery of working products, which are successively improved, to a customer for immediate feedback and acceptance.
  • Typically, a product is delivered at the end of each sprint or iteration for demonstration and feedback.
  • In this feedback technique, a customer can review the product and provide updated requirements.
  • Changed/updated/refined requirements are welcomed in the agile process to ensure the customer receives a valuable and quality product.
  • A sprint or iteration typically lasts from two to four weeks and at the end a new and improved product is delivered, incrementally.
  • [The Art of Agile Development. James Shore.]

Internal and external factors

  • When considering whether to apply new agile practices, several internal and external factors should be considered.
  • Internal factors include whether the project is developing new processes or products; whether the organization is collaborative and emphasizes trust, adaptability, collective ownership, and has minimal or informal project management processes; the size, location, and skills of the project team.
  • External factors include the industry stability and customer engagement or involvement.
  • Generally, agile is best suited to developing new processes or products for an organization that is collaborative and emphasizes trust, adaptability, collective ownership, and has minimal project management processes by an agile/project team that is relatively small in size, is collocated, and is cross-functional in skill.
  • Additionally, agile is known to succeed in industries that are quickly adapting to disruptive technologies as opposed to industries that are stable and perhaps inflexible to adaptive approaches.
  • And, lastly, the component of customer involvement and engagement cannot be stressed enough; the more participation, the better.
  • [The Art of Agile Development. James Shore.]

Intrinsic quality

  • “Higher the technical debt means lower the intrinsic quality.”
  • Intrinsic quality is an internal quality of the product, having good design and implementation improves the intrinsic quality and reduces the technical debts.
  • Intrinsic quality is required to deliver continuous value to the customer, it’s an internal quality of product which is not visible to the end user but needed to make product adaptable for future need.

IRR

  • The internal rate of return (IRR) is a financial metric used to measure and compare the profitability of investments.
    • Select project with biggest IRR.

Iteration
– A short, fixed time period (typically between 1 and 4 weeks) during which the team produce a potentially deployable release of software for evaluation. Scrum calls them Sprints.

Iteration events

  • For productive iterations, each team member should attend all meetings Events as a “PEER”.
  • Plan each iteration (Iteration Planning)
  • Expect daily updates (Daily Stand-Up)
  • Examine product results (Iteration Review)
  • Reinvent processes for next iteration (Iteration Retrospective)

Kaizen

  • The Japanese word « kaizen » means change for the better. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
  • The word kaizen means “continuous improvement.” It is a system of continuous improvement in quality, technology, processes, company culture, productivity, safety, and leadership. It comes from the Japanese words (“kai”) which means “change” or “to correct” and (“zen”) which means “good.”

Kanban

  • Kanban is a strategy for optimizing the flow of value through a process that uses a visual, workin-progress limited pull system.

Minimum marketable feature (MMF)

  • A Minimal Marketable Feature (MMF) is a software feature or product feature that is both minimal and marketable.

NPV

  • Net Present Value (NPV) is a metric used to analyze the profitability of an investment or project.
    • Select project with biggest NPV.

Pair Programming

  • Pair Programming is the XP practice of two developers working at one PC to write and review code together.

Parking Lot Diagram

  • Parking Lot Diagram is a status reporting graph used in FDD to summarize project progress across a number of functional areas

Participatory decision models

  • Participatory decision models : e.g., inputbased, shared collaboration, command
  • To build trust among the team, agile believes heavily in participatory decision models where team members collaborate to make decisions.
  • Although a team leader or scrum master will need to make some decisions individually, many decisions can be made by the team collectively.
  • These agile principles are also known as collective ownership, self-organization, and self-discipline.
  • In collective ownership, the team members are equally responsible for project results and are empowered to participate in decision making and problem solving processes.
  • [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

PDCA

  • PDCA (plan–do–check–act or plan–do–check–adjust) is an iterative four-step management method used in business for the control and continuous improvement of processes and products.
  • PDCA was made popular by Dr W. Edwards Deming, who is considered by many to be the father of modern quality control.

Planning Game

  • A facilitated workshop during which developers and business representatives estimate work tasks and plan upcoming iterations.
  • Extreme programming (XP) uses the planning game to prioritize features based on user stories and release requirements. [The Art of Agile Development. James Shore.]

Planning poker

  • Planning poker is a popular agile game used to estimate the relative work effort of developing a user story.
  • Each team member has a deck of cards with various numbered values which he or she can draw from to « play (showing one card) » to indicate an estimated point value of developing a user story.
  • [Coaching Agile Teams. Lyssa Adkins.]

PMI’s Code of Ethics and Professional Conduct

  • PMI professional code of conduct
    • The Project Management Institute (PMI) outlines a professional code of conduct in the PMI Code of Ethics and Professional Conduct document. [PMI Code of Ethics and Professional Conduct. Project Management Institute.]

Problem-solving techniques

  • Literally thousands of decisions are made in the course of a project.
  • Many of these decisions are made in response to problems that inevitably arise and confront the agile team.
  • Therefore it is essential that an agile team is properly versed in problem-solving strategies, tools, and techniques.
  • Some common problem-solving techniques include: ask it loud; revisit the problem; 5Y; sunk cost fallacy; devil’s advocate; be kind, rewind; asking probing questions; and reflective/active listening.
  • [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Problem-solving strategies, tools, and techniques

  • Literally thousands of decisions are made in the course of a project.
  • Many of these decisions are made in response to problems that inevitably arise and confront the agile team.
  • Therefore it is essential that an agile team is properly versed in problem-solving strategies, tools, and techniques.
  • Some common problem-solving techniques include: ask it loud; revisit the problem; 5Y; sunk cost fallacy; devil’s advocate; be kind, rewind; asking probing questions; and reflective/active listening.
  • [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
  • 5 Y :
    • Five (5) Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem.
    • The primary goal of the technique is to determine the root cause of a defect or problem
  • Common problem-solving techniques :
    • Ask it loud
    • Revisit the problem
    • 5Y
    • Sunk cost fallacy
    • Devil’s advocate
    • Be kind
    • Rewind
    • Asking probing questions
    • Reflective/active listening

Product knowledge

  • Cohn’s definition of product knowledge is knowledge about what features will or will not be developed in a project. [User Stories Applied: For Agile Software Development. Mike Cohn.]

Program Evaluation and Review Technique (PERT)

  • Program Evaluation and Review Technique is a network diagram based modeling technique used to determining likely project durations and identify critical path activities.
  • If done only at the start of a project it is thought by Agilists to suffer from premature specification issues.

Project charter

  • The project charter is an important governing document that requires all stakeholder participation.
  • Although experts recommend it not be longer than a page in length, creating a project charter can be challenging, as all stakeholders must participate and come to a consensus.
  • Three key elements should be included in a project charter: vision, mission, and success criteria. Vision is the ‘why’ or rationale of a project.
  • Mission is the ‘what’ of the project and describes what the team will accomplish to reach the vision.
  • Success criteria are management metrics that define ‘how’ the project will be deemed successful.
  • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Project Management Body of Knowledge (PMBok)

  • Project Management Body of Knowledge is the PMI’s reference text of knowledge areas that project managers should understand.
  • The principle basis of the PMP exam.

Project Management Institute (PMI)

  • Project Management Institute
    • A project management standards and certification body widely used in North America.
    • Creator of the PMBOK Guide and assigner of CAPM, PMP, PMI-ACP and others certifications.

Project Management Office (PMO)

  • Project Management Office is a group responsible for centralizing project management best practices and assisting with best practice application.
  • Their actual roles will vary from organization to organization.

Project Management Professional (PMP)
– Project Management Professional is the designation given to project managers who have passed the PMI’s PMP Exam.

PRINCE2

  • PRINCE2 stands for Projects, IN, Controlled, Environments version2, a European based project management standards and certification body.
  • PRINCE2 is structured, but has less lifecycle guidance than the PMBOK Guide and so is generally easier to integrate agile methods within.

Prioritized Requirement

  • A description of system functionality that has been prioritized by the business.
  • The unit for planning, estimation, and reporting.
  • Some agile methods use the term Story, or Feature.

Product Backlog

  • The prioritized list of stories, features, or requirements that the project works it’s way through.
  • The closest thing to a list of requirements a traditional PM will find.
  • Product Backlog

Project Support Office (PSO)

  • Project Support Office, similar to a PMO, a group responsible for centralizing project management best practices and assisting with best practice application.
    • Their actual roles will vary from organization to organization.

PV

  • Present value
    • PV = Future Value / (1 + I)^n where I is the interest rate and n is the number of periods.

Relative prioritization/ranking

  • Relative ranking/prioritization involves ordering a list of items (e.g., User Stories, epics, tasks, defects, etc.,) based on a team-defined definition of priority. [The Art of Agile Development. James Shore.]
  • Value, cost, and risk are key elements to consider when prioritizing User Stories. [Agile Estimating and Planning. Mike Cohn.]

Refactoring

  • The process of improving code (by clean-up, simplification, etc) to make it easier to maintain and expand in the future. Refactoring is a necessary step to keep the cost of changes low.
  • A change that is made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior is referred to as…
  • Code refactoring :
  • Code refactoring is method of improving working source code to make it more efficient, readable, extensible, maintainable and less complex.
  • Through refactoring one is able to restructure source code modifying internal code without changing the external behavior.
  • [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
  • Test Driven Development (TDD)

Reflection or retrospective

  • During reflection or Retrospectives, an agile team reserves time to reflect on the work it has completed with the objective of continuous improvement.
  • In these self-assessment/team-assessment events, topics can include: lessons learned from successes and failures; team standards that worked, failed, or were not properly followed; and other areas of improvement.
  • [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Requirements Sign-off

  • Formal sign-off on a requirements document to indicate that the requirements are complete and agreed.
  • Subsequent changes will require submission through a change management process.

Retrospective

  • Retrospective is a facilitated workshop exercise held at the end of iterations and releases in which project stakeholders are asked to reflect back on the work to date and recall:
  • What has worked,
  • Areas for improvement, and
  • Suggestions for the future.
  • Similar to Lessons Learned sessions but performed throughout the project.

ROI

  • Return on Investment (ROI) is a metric used to evaluate the efficiency of an investment or to compare efficiency among a number of investments.
    • Select project with biggest ROI.

Rolling wave plan or rolling look ahead plan

  • When using a rolling wave or rolling look ahead plan for complex projects, only work that is about to be completed for the next few iterations – where requirement details are better understood – are planned.
    • The plan includes all interdependent agile project teams to ensure successful integration of tasks.
    • [Agile Estimating and Planning. Mike Cohn.]
  • In large, complex projects, agile project leaders can facilitate iteration planning by using a rolling wave or rolling look ahead plan, which involves making plans for the next few iterations at a time. [Agile Estimating and Planning. Mike Cohn.]

Rolling Wave Planning

  • The PMBOK’s term for acknowledging that planning needs to be iterative and repeated throughout the project.
  • Agile teams can you this concept to help introduce iteration plans and reprioritization.

Rational Unified Process (RUP)

– Rational Unified Process is an iterative methodology owned by Rational (IBM) that can be made to be agile through strict controls on the artifacts selected, but implemented by many organizations as a heavier than agile, iterative approach

Scrum

  • Scrum is an agile framework popularized by Jeff Sutherland, Ken Schwaber and others employing 15 to 30 day Sprints (iterations) and minimalist controls.

Scrum Master

  • The Scrum Master is the iteration manager on a Scrum project.
  • Often performed by the project manager to team lead, the Scrum Master is responsible for managing the iterative development process.

Schedule Performance Index (SPI)

  • Schedule Performance Index is a measure of project progress from a timeline perspective.
  • Agile projects can obtain the same metric by dividing the # Completed Features by the # Planned Features.

Software Process Improvement (SPI)

  • Software Process Improvement.

Spike

  • Spike is a short focused period of development undertaken to prove new technology.
  • For example “We’ll spike the Oracle 10g compatibility”

Sprint

  • Sprint is an iteration, a period of time to undertake development.
  • In Scrum Sprints are typically 15 to 30 days in duration.

Standards

  • Aspirational standards
  • Aspirational standards are standards that every professional should strive to uphold, but are not compulsory. [PMI Code of Ethics and Professional Conduct. Project Management Institute.]
  • Mandatory standards
  • Mandatory standards are required and often backed by law. [PMI Code of Ethics and Professional Conduct. Project Management Institute.]

Standup meeting

  • Daily stand-up meeting is a short (15 minutes or less) daily meeting during which team members report on what they accomplished since the last meeting, what they plan to accomplish today, and report any impediments or blockers to making progress.

Story

  • A User Story is a shorthand requirements document that acts as a placeholder for further discussion and elaboration with a user representative to determine the true business requirement.
  • The unit for prioritization, planning, estimation, and reporting in XP.
  • Some agile methods use Features, or Prioritized requirements as their requirement units.

Schedule Variance (SV)

  • Schedule Variance is a measure of how much ahead or behind schedule we are.
  • Agile projects can get the same information by deducting the number of features actually delivered from the number of features planned to be delivered by now.

Tacit knowledge

  • Tacit knowledge is the « sum of all knowledge from all people on a project team. » [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Technical debt

  • Technical Debt is not an XP practice.
  • Technical debt is total sum of less than perfect design and implementation decisions in the product, technical debt needs to be monitored and controlled.
  • Technical debt is the total amount of less-than-perfect Design and implementation decisions in your project Team should strive to have minimum technical debts, and team should reduce technical debt by adapting refactoring practice of XP.

Test Driven Development (TDD)

  • Test Driven Development (TDD) is the practice of writing tests first to better understand the requirements of new functionality.
  • The test fails and code is written until the test passes.

Traditional plan to Agile Baseline

  • an approved and saved project plan used to compare progress against.

Values

  • The following are community values of the PMI agile community of practice community charter:
  • Vision,
  • Servant Leadership,
  • Trust,
  • Collaboration,
  • Honesty,
  • Learning,
  • Courage,
  • Openness,
  • Adaptability,
  • Leading Change,
  • Transparency
  • [PMI Agile Community of Practice Community Charter. Project Management Institute.]

Value-based analysis

  • Value-based analysis strives to understand how value, as defined by the customer, relates to various components of the product, like features and tasks.
  • Features are often prioritized with prioritization based on value and risk.
  • Prioritization can be performed using the MoSCoW or Kano method and through the use of risk-to-value and cost-to-value matrices.
  • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Value chain

  • Collaboration, responding to change, working software and individuals and interactions are on the higher side of the customer value chain.
  • Processes and tools, comprehensive documentation, contract negotiation and following a plan are on the lower side of the customer value chain.
  • The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Assessing and incorporating community and stakeholder values

Value stream mapping

  • Value stream mapping is a collaborative process analysis technique where a diverse team depicts/maps a process to identify where waste occurs and where improvements can be made.
  • It is an example of a process analysis technique. Like value stream mapping, process mapping is also used to map a process to identify bottlenecks (places where processing slows and inventory can build).
  • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Velocity

  • Velocity is the rate of development progress.
  • Usually expressed as stories completed (and tested) per iteration.
  • The primary measure of development speed.

Vertical-market software

  • Vertical-market software includes solutions for many organizations within one industry (e.g., pharmaceutical software).

Work Breakdown Structure (WBS)

  • Work Breakdown Structure is an org chart style, hierarchical breakdown of project deliverables or functionality.
  • If done very early or taken very deep in detail it may be considered by agile teams as a form of Big Design Up Fron (BDUF).

XP / eXtreme Programming

  • eXtreme Programming (XP) is an agile method popularized by Kent Beck, Ron Jefferies, and others that promotes techniques such as pair programming and user stories.
  • Sit together (XP advocates an open space big enough for the whole team).
  • Slack (XP recommends that in any plan it is better to include some minor tasks that can be dropped if you get behind. You can always add more stories later and deliver more than you promised.).
  • Energized (work only as many hours as you can be productive and only as many hours as you can sustain).

YAGNI

  • You Ain’t Going Need It
    • an XP based mantra that reminds us to keep designs simple and do not over complicate solutions for potential future expansion that may never be required.

This Agile dictionary was wrottten by Mike Griffiths, an independent consultant specializing in effective project management.

Mike was involved in the creation of DSDM in 1994 and has been using agile methods (Scrum, FDD, XP, DSDM) for the last 25 years.

He serves on the board of the Agile Alliance and the Agile Project Leadership Network (APLN).

He is also a contributor to the PMBOK and trainer for the PMI Seminar Worlds program.

He maintains a leadership and agile project management blog at www.LeadingAnswers.com

More informations at PMI-ACP exam

Leave a Reply

Your email address will not be published. Required fields are marked *