21 November 2024
Agile frameworks and terminology / PMI-ACP / PMI-ACP exam

Agile terminology

admin5315by admin5315

3 C

  • Ron Jeffries’ three Cs for User Story definition are card, conversation, confirmation. [User Stories Applied: For Agile Software Development. Mike Cohn.]

5 WHY’s

  • a systematic approach to analysing identifying the root cause of a problem / cause-and-effect for the problem or issue
    perform by repeatedly asking the question “Why” for at least 5 times until the root cause has been identified
    • imaginary example : Looking for the root cause for failing the PMI-ACP® Exam
      • Why did I fail the PMI-ACP® Exam?
        • Because I got a lower mark than the passing mark
      • Why did I get a lower mark?
        • Because I was not sure about the answers to many questions.
      • Why was I not sure about the answers to many questions?
        • Because I could not remember some facts for the exam.
      • Why couldn’t I remember some facts for the exam?
        • Because I was not familiar with the PMI-ACP® Exam content.
      • Why was I not familiar with the PMI-ACP® Exam content?
        • Because I did not spend enough time revising the PMI-ACP® Exam notes.
  • See Agile Problem Solving

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.
  • See Agile and the product quality

Acceptance Test Driven Development (ATDD)

  • Acceptance Test Driven Development (ATDD) is similar to Test Driven Development (TDD) in that it requires programmers to create tests first before any product code.
    • The tests in Acceptance Test Driven Development (ATDD) are aimed at confirming features/behaviors that the intended software will have.
    • The iterative cycle of Acceptance Test Driven Development (ATDD) with its four steps can be remembered as the four Ds : 1) Discuss, 2) Distill, 3) Develop, and 4) Demo.
      • 1) Discuss:
        • The agile team and customer or business stakeholder discuss a User Story in detail.
        • Talking about the expected behaviors the User Story should have and what it should not.
      • 2) Distill :
        • The Developers takes those items learned from the discussion and distills them into tests that will verify and validate those behaviors.
        • The distillation process is where the entire team should have a good understanding of what « done » (or completed, see Definition of Done (DoD)) means for a User Story.
        • That is, what the acceptance criteria are.
      • 3) Develop :
        • After distillation, the team develops the test code and product code to implement the product features.
      • 4) Demo :
        • Once the product features have been developed, the team demonstrates them to the customer or business stakeholders for feedback.
    • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Active listening

  • There are 3 levels of listening skills :
    • Internal Listening
      • How is this going to affect me ?
        • thinking about how things will affect me
    • Focused Listening
      • Put ourselves in the mind of the speaker and look for emotional indicators
        • trying to understand what are the speaker is really trying to say
    • Global Listening
      • Adding high levels of awareness on behavior of the speaker & observe
        • keep track of not only what has been said but also the different signs and gestures the speaker employs to convey the full message
  • See Agile communications

Adaptation

  • Perform periodic Retrospectives to allow adaptation of the planning process to maximize value creation.
    • Adapt the project plan continually to reflect changes in project requirements, priorities, stakeholder feedback and environmental factors.
    • See Inspect and Adapt

Adaptive

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

Adaptive leadership

  • Highsmith defines adaptive leadership as two dimensional :
    • Being agile and doing agile.
      • Being agile includes focusing on cornerstones of agile project management, like incremental delivery, continuous integration, and adapting to changing requirements.
      • Doing agile includes several activities that an agile leader must do: do less; speed-to-value, quality, and engage and inspire.
      • [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Afferent Coupling (Ca)

  • Afferent Coupling is a code quality metric.
  • The number of classes in other packages that depend upon classes within the package is an indicator of the package’s responsibility.

Afferent couplings (Ca) and Incoming (Fan-in)

  • Afferent (incoming) couplings :
    • Who depends on you.
    • Measure of how many other packages use a specific package.
    • Incoming dependencies.
    • Afferent couplings signal inward.
  • Afferent Coupling measures how many classes depend on a given class and has the following characteristics :
    • Classes with high afferent will affect other classes when changes are made.
    • A large afferent coupling can indicate that you should reconsider the responsibilities of the class, because it will be very difficult to make changes to this class later when so many other classes are dependent on it

Affinity estimating

  • Affinity estimating is the process of grouping requirements into categories or collections.
  • Affinity estimating is a method to predict the work effort, typically in story points, of developing a User Story.
    • It is particularly useful for large Product Backlogs.
    • Although several methods exist, the basic affinity estimating model involves sizing User Stories on a scale from small to large.
    • The scale can be a Fibonacci sequence or t-shirt sizes and is typically taped to a wall in a large conference room.
    • Participants then attach their User Stories to the wall as estimates.
    • It is often done in silence and has several iterations until the user stories have been estimated.
    • [The Art of Agile Development. James Shore.]
  • The Fibonacci sequence begins with 0 and 1 and every successive number is the sum of the previous two numbers.
    • Therefore the Fibonacci sequence begins 0, 1, 1, 2, 3, 5, 8, 13, etc.
    • In Planning poker, a 1 is removed because it is redundant.
    • [Agile Estimating and Planning. Mike Cohn.]
  • When estimating an agile project, a top-down approach is typically used.
    • This involves high-level estimation at first, followed by more detailed estimation.
    • [Agile Estimating and Planning. Mike Cohn.]
  • See Agile estimation

Agile

  • Agile development is a broad term for many different methodologies that adhere to agile manifesto.

Agile Adaption

  • Make changes to the project, product and processes to deliver best customers value and the special circumstances of the project environment
    • may involve process tailoring, continuous integration, adaptive leadership, soft skills negotiations, delivering business value, revised vendor management, change management
  • Process Tailoring
    • Agile framework or methodologies are not intended to be “one-size-fit-all”
    • the Agile methodology and processes can be altered according to different projects (e.g. in terms of team size, nature, resources, criticality, etc.)
    • the adaptation / process tailoring can be raised in the iteration retrospective to be carried out in the next iteration
    • However, in the beginning of any projects, it is generally recommended to implement the Agile methodologies as it is for the first few iterations for assessment of the suitability before changes / process tailoring are introduced
      • to have better understanding of the values of standard Agile methods and the relationship between different processes of Agile methodologies as some processes are mutually dependent
    • It is recommended to follow the Shu-Ha-Ri model (by Alistar Cockburn) if you would like to make changes
      • Shu-Ha-Ri originates from masters of Japanese Noh theater
        • Shu
          • Obeying the rules
        • Ha
          • Consciously moving away from the rules
        • Ri
          • Unconsciously finding an individual path
    • See Shu Ha Ri
    • Agile common frameworks or methodologies

Agile Adaptation Terms

  • Velocity
    • a unit to measure the speed of the team
      • e.g. the number of story points in each iteration which is very useful for planning future releases
    • partially finished tasks in an iteration will NOT be counted towards velocity
      • e.g. if a task with 100 story points is 90% complete, it will contribute 0 story point to the iteration
  • Cycle time
    • cycle time is the amount of time for a feature from start (entering into the product backlog) to finish (done), the shorter the cycle time, the better
  • Burn rate
    • a measure of how fast money is burnt / the amount of cost estimated over a given period of time (e.g. $1000 per day)
  • Escaped defects
    • escaped defects are defects that are not discovered by the team but by the customer, escaped defects are a measure of the effectiveness of testing and quality control measures
      • i.e. if the escaped defects increase, root cause analyses such as five WHYs or fishbone diagram should be carried out with a view to reduce escaped defects
  • Agile smells
    • Agile term for “symptoms of a problem”, they are signs that the Agile project is not running properly and problems are in the making
  • Verification
    • ensures functionality meets requirements as described in the requirement documentation
  • Validation
    • ensures the deliverable works as intended
  • Refactoring
    • a technique used in programming project to review codes, re-organize and simplify the code without changing the behavior for easier maintenance
    • See Test Driven Development (TDD)
  • Kaizen
    • a Japanese management philosophy in which the project and processes are being checked and improved continuous for better value delivery

Agile approach

  • 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 Coaching and Mentoring

  • Coaching and mentoring are needed to help steer the team in the right direction:
    • coaching
      • help achieving (personal / organization) goals
    • mentoring
      • pass on skills, knowledge and experience

Agile common frameworks or methodologies

Agile communications

Agile communication tooling

  • Empathy
  • Face-to-face communication
  • Leading
  • Regular communication
  • Environment
  • Information radiator
  • Osmotic communication
  • No-collocated / distributed team
  • Stand-up meeting
  • Team space
  • See Agile communications

Agile contracting

  • Agile planning provide great flexibility and allow us to manage changing requirements & priorities.
    • This flexibility can create problems when defining acceptance criteria for contracts and when
      we outsource work.
  • The goal of Agile contracting is closer cooperation between Team and Customer
    • The goal is represented in the 3rd entry of the manifesto « Customer collaboration over contract negotiation »
    • AGILE requires more trust between the partners than the traditional method
    • For trust-invested partners AGILE gives an enormous competitive advantage
    • For untrusting clients, agile contracting will be a though sell
  • Agile vendor management and contracts

Agile contracts

  • For companies that are familiar with fixed-price contracts, where requirements are agreed upon before contract closing, adopting agile can be a weary initial venture.
    • Fixed-price contracts, although typical of traditional projects where scope is defined ahead of time, are not well suited for agile.
  • Instead, other contract vehicle types are recommended for agile efforts, these include :
    • A general service contract for the initiation phase and separate fixed-price contracts for iterations or user stories;
    • Time-and-material contracts;
    • Not-to-exceed with fixed-fee contracts;
    • Incentive contracts (e.g., fixed price with incentive; cost-reimbursable with award fee).
    • Cost-reimbursable with award fee
    • Fixed-price with incentive
  • [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
  • See Agile vendor management and contracts

Agile Contracts and cost approaches for services the agile management way

  • Evaluating cost structures for an agile project
    • Fixed-price projects:
      • A vendor works on the product and creates releases until the vendor spends all the money in the budget, or until it delivers enough product features, whichever comes first.
    • Fixed-time projects with a specific deadline
      • For example, you may need to launch a product for a specific event or to coincide with the release of another product.
      • With fixed-time projects, you determine costs based on the cost of the vendor’s team for the duration of the project, along with any additional resource costs, such as hardware or software.
    • Time-and-materials projects
      • Work with the vendor lasts until enough product functionality is complete, without regard to total project cost.
      • You know the total project cost at the end of the project, after your stakeholders determine that the product has enough features to call the project complete.
    • Not-to-exceed projects
      • Projects in which time and materials have a fixed-price cap.
  • See Agile vendor management

Agile Control limits

  • Choose the control chart which is fitting for your data
  • Determine the appropriate time period required for collecting the data and plotting the data collected
  • Collect the actual data construct your chart and analyze the data
  • Look for out for control signals on the control chart and investigate the cause
  • See Agile control limits

Agile development process

  • The agile development process has multiple iterations that focus on specific product features, encourages heavy customer feedback, and is adaptive to changing customer requirements. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Agile Estimation and Sizing

  • Agile estimation and sizing
    • Relative Sizing
      • Agile project management makes use of relative sizing (e.g. story points) as opposed to the use of exact units like money and time in traditional project management for estimation as Agile projects are more prone to changes, making use of relative sizing will be more flexible yet still give a reference for meaningful estimation
    • Ideal Time
      • a unit used in estimation of Agile tasks: ideal time is a block of uninterrupted period to focus solely on the task without any distractions e.g. email, phone call, toilet break, etc..
      • Though ideal time is NOT realistic in actual world, it does give an accurate unit to begin working with (e.g. by multiplication of a factor of 2 to 3 to give a reasonable estimate)
    • Wideband Delphi Estimating
      • similar to the Delphi technique but discussion about details of the requirements is allowed in the beginning to allow each individual to have a common understanding of the scope of the tasks, each participant will then try to give an estimate for the user stories, etc. with relative sizing on their own; repeat the process until a consensus is reached
        Planning Poker
      • each members need to select from a deck of cards (with ?, 0, 1, 2, 3, 5 …) to express their estimation of the story points for a User Story, discussion follows until a consensus is reached
    • Affinity Estimating / T-shirt Sizing – assign a size (e.g. T-shirt sizing: S, M, L, XL, XXL) to User Stories instead of giving a more concrete unit, this method is ideal if the scope / details of the task are not quite concrete
    • The accuracy of estimation will improve over time in the form of “Cone of Uncertainty” (25%-400% from the very beginning to within several percentage near complete) as more knowledge of the project is gained at a later stage.
    • See Agile estimation

Agile Experimentations

  • Agile projects make use of empirical process control for project decisions, ongoing observation and experimentation are carried out during project execution to help and influence planning
  • Introduce Spike (including Architectural Spike) to carry out a technical investigation to reduce risks by failing fast

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.]
  • See Agile failure modes and alternatives

Agile failure modes and alternatives

  • The top 12 causes of agile failure (Agile failure modes and alternatives) 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.A reversion to the traditional or ‘old-way’ of doing business occurs because change is hard.
  • [Coaching Agile Teams. Lyssa Adkins.]
  • See Agile failure modes and alternatives

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.
  • See Agile common frameworks or methodologies

Agile frameworks and terminology

  • Common frameworks or methodologies used within agile include: Scrum, eXtreme Programming (XP), Lean Software Development (LSD), Crystal methodologies, 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.
  • See Agile terminology

Agile games / Innovation games

  • The phrase innovation game refers to a form of primary market research developed by Luke Hohmann where customers play a set of directed games as a means of generating feedback about a product or service.
    • The research is primary because the data collected is gathered directly from customers or prospects and is intended to answer a specific research question.
    • Secondary research is data collected previously by others, usually through primary research, that may or may not address a specific research question.
    • “Customers” who play innovation games are commonly direct recipients or consumers of a specific product or service.
    • In some cases, though, game players may be any person or system who is or would be affected by a product or service.
  • See Agile games

Agile iron triangle

  • The agile iron triangle includes cost, scope, and schedule as its parameters.
    • Constraints is a parameter included in the agile triangle, not the agile iron triangle.
    • [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Agile Leadership Style : Servant Leadership

  • traditional leadership and management emphasizes on command-and-control
    • i.e. Theory X – workers are lazy and need to be monitored closely
  • servant leaders will lead by serving to ensure the needs of team members are met and roadblocks are cleared
    • [i.e. servant first, leader second mentality] (Theory Y – team members are self-motivated)
  • an Agile servant leader needs to :
    • communicate and re-communicate project vision
      • maintain a common vision to drive the team to perform
    • protect the team from interference, distractions and interruptions
    • remove impediments to the team’s performance
    • carry food and water
      • i.e. provide all the resources for the team to perform, including motivate the team, provide trainings

Agile Manifesto

  • The Agile Manifesto developed by the Agile Alliance covers 4 values and 12 principles.
    • The four values are :
      • 1) individuals and interactions over processes and tools,
      • 2) working software over comprehensive documentation,
      • 3) customer collaboration over contract negotiation, and
      • 4) responding to change over following a plan.
    • The 12 principles are :
      • 1) focusing on satisfying the customer,
      • 2) welcoming change,
      • 3) delivering working software frequently,
      • 4) ensuring that business people and developers work together,
      • 5) motivating the individuals involved in development,
      • 6) using face-to-face communication whenever possible,
      • 7) working software as the primary measure of progress,
      • 8) maintaining a constant pace of development,
      • 9) paying continuous attention to technical excellence and good design,
      • 10) aiming for simplicity,
      • 11) using self-organizing teams, and
      • 12) regularly reflecting on how to become more effective.
    • [Manifesto for Agile Software Development. Agile Alliance.]

Agile Methodologies

Agile Methods

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

Agile modeling

  • Agile Modeling is a practice-based methodology (including a collection of values, principles, and practice) for effective modeling and documentation of software-based systems based on best practices
    • a model is a pre-defined way of doing things
  • Agile Modeling is more flexible than traditional modeling methods to be used in traditional project management in order to fit the fast-changing environments of Agile projects
    • also refers to the various modeling techniques that are commonly used on Agile projects
  • Agile models are often lightweight (often hand sketched without being polished), easy to change and barely sufficient, e.g. use case diagrams, data models, screen designs
  • Agile modeling is describe in the Crystal development process
    • The Crystal development process is cyclical/iterative, its primary components are chartering, delivery cycles, and project wrap-up.
  • Main value of creating a model is opening a framework to the discussion of how the solution should be conceived.
  • See Agile analysis and design

Agile plan

  • Showing dependencies of one task on others is not a characteristic of an agile plan.
    • Since in agile we focus on creating a pull system rather than push system and we start with a top level plan first.
    • Principle of last responsible moment : in agile we do things at Last Responsible Moment.

Agile Planning

  • Planning of Agile projects occurs at multiple levels: strategic, release, iteration, daily using rolling wave planning and progressive elaboration to allow flexibility and adaptability.
    • Encourage key stakeholders participation in planning and ensure clear communication of planning results to improvement commitment and reduce risks.
    • Manage stakeholder expectations by communicating appropriately detailed information to create a common understanding of the deliverables.
  • Traditional project management triangle :
    • “Time, Cost and Functionality (Scope)” fixed
  • Agile project management inverted triangle model :
    • “Cost (Resources), Time and Quality” fixed, Product Backlog (Scope)” variable
  • Core Agile project management phases:
    • envisioning
    • speculating
    • exploring
    • adapting
    • closing
  • Agile Planning (using Deming Cycle: Plan-Do-Check-Act)
  • Agile projects must be planned at multiple levels (strategic, release, iteration, daily) while ensuring stakeholder engagements
    • though Agile project are not plan-driven, planning is an important activity:
    • initial planning (usually with less planning upfront)
      • strike a balance of balancing risks and planning investments
    • re-planning and midcourse adjustments with gained knowledge from the execution of the project
    • carry out only just-in-time planning as the project is ever evolving, making use of rolling wave planning
      • break down the planning into stages, with the near-time planning to be carried out first
    • progressive elaboration
      • knowledge about the product and requirements will be clearer as the time goes by, those will be revisited and refined continually
  • See Agile planning, monotoring and adapting

Agile Planning Artifacts and Meetings

  • The Product Vision Statement is developed by the Product Owner (with the help of the team) to state clearly the purpose and value of the product
  • The Product Roadmap contains the about the schedule and cost milestones which acts as an overview of the planned releases of the project, the Product Roadmap will change over time
  • Personas
    • a tool used in requirement collection and testing in which realistic depiction of likely users for the product are created, these users can be real or fictitious
    • Extreme Persona
      • extreme persona is persona taken to the extreme (with extreme characters / requirements) in order to identify user stories which would be missed otherwise
  • Wireframes
    • Wireframe are sketch graphical presentations of how the requirements are fulfilled (usually as interface designs), can act as a kind of fast requirement documentation
  • Release Plan
    • responsible by the customer / Product Owner with the help of project team in release planning to document the availability of features over time, subject to changes depending on actual progress / change requests
  • Agile Planning Terms
    • Agile Themes
      • a theme is usually assigned for an iteration in which similar functions are grouped to be done in a batch to maintain focus of the team, e.g. bug fix, reporting, etc.
    • Epic Story
      • a large block of functionality (usually requires several iterations), epic stories will later be disaggregated into smaller user stories for estimation and implementation
    • User Story
      • User Stories usually take the format of “As a [role], I want [need] so that [business value]”
      • to describe the requirements in real world scenarios
      • often written on Story Cards
      • User Stories need to be Independent, Negotiable (can be discussed on implementation), Valuable, Estimatable (with adequate info for meaningful estimation), Small, Testable [INVEST]
      • [Ron Jeffries’ three Cs of user story] Card, Conversation, Confirmation
    • Story Maps
      • are overview of how different user stories are related to each other in the project
    • Features
      • a capabilities / group of functionalities that is of value to the end user
    • Tasks
      • the underlying jobs / development work to fulfill a user story, tasks are taken up by the team members through self-organization
    • Spikes
      • Spike is a short experimental test to help decisions making, e.g. trying a new technology for feasibility study
      • Architectural Spike
        • an investigation taken to explore the architectural aspects of the setup
    • Time-boxing
      • time-boxing is a concept for time management by treating time as fixed blocks
      • once the allotted time (time-box) is up, the work must be stopped regardless of whether it has been finished
        with fixed start time, fixed end time and fixed duration for the activity to control the risk and progress
        time-boxing allows the team to focus on the essential works and reduce wastes
  • See Agile planning, monotoring and adapting

Agile Planning Stages

  • Product Vision
    • usually revised once a year, a document created by Product Owner describing what the product is, who will and why use it, and how the product supports company strategy
  • Product Roadmap
    • revised twice a year, a document created by Product Owner describing the high-level product requirements and the timeframes for deliverables, providing a visual overview of all the planned releases and major components
      may be in the form of story maps
      • a diagram indicating the sequences of backbone, walking skeleton and optional features to be released over time
  • Release Plan
    • revised twice / four times a year, a document created by Product Owner describing the high-level timeline for product releases (features with higher values are given higher priority in the releases)
      • release planning is the meeting to plan the project schedule at a strategic level for delivering an increment of product value to the customers (can be date driven or feature driven)
  • Sprint Plan / Iteration Plan
    • revised once a month or less / an iteration, a document created by Product Owner, Scrum Master and Developers describing Sprint goals, tasks and requirements and how those tasks will be completed
      • iteration 0 is for carrying out tasks before the actual development work begins for technical and architectural setup (e.g. spikes) and gathering initial requirements into the backlog, etc.
        • iteration H may represents hardening iteration which is a time used to test and prepare the launch software
    • Iteration Planning vs Release Planning
      • Iteration planning involves schedule development at lower/detailed level about tasks and time
      • Release planning involves schedule development at high level about features and iterations
  • Daily Stand-up /Daily Scrum
    • daily for 15 minutes, a planning meeting to be attended by project team and stakeholders (as observers only) to discuss on the following 3 questions:
      • What was completed yesterday?
      • What will be done today?
      • Any roadblocks/impediments found
  • Sprint Review
    • monthly or less, at least an hour, by Sprint, a meeting scheduled at the end of each Sprint for demonstration of working product/Increment/deliverable to stakeholders for feedback and/or acceptance
  • Sprint Retrospective
    • monthly or less, at least an hour, by Sprint, a meeting scheduled at the end of each Sprint to be attended by team members only, will discuss improvements on product and process to enhance efficiency and effectiveness
  • Retrospective Meeting vs Review Meeting
    • Retrospective meeting is for the development team only (stakeholders are not invited) with the primary purpose of process improvement
    • Review meeting is for demonstration of deliverables with management, product owner and stakeholders; new backlog item(s) may be identified together with the customers to be added in the next iteration
  • Retrospective Meeting vs Lessons Learned Meeting
    • Retrospective meeting is carried out once per iteration to timely identify areas for improvement for immediate action to benefit the project itself
    • Lessons Learned meeting (in traditional project management) is carried out at the end of the project / phrase as the project closure activity and all the lessons learned are to be identified and documented (according to PMBOK® Guide) so that they will benefit upcoming projects
  • See Agile planning, monotoring and adapting

Agile Planning Terms

  • Agile Themes
    • a theme is usually assigned for an iteration in which similar functions are grouped to be done in a batch to maintain focus of the team, e.g. bug fix, reporting, etc.
  • Epic Story
    • a large block of functionality (usually requires several iterations), epic stories will later be disaggregated into smaller User Stories for estimation and implementation
  • User Story
    • usually takes the format of “As a [role], I want [need] so that [business value]”
    • to describe the requirements in real world scenarios
    • often written on Story Cards
    • User Stories need to be Independent, Negotiable (can be discussed on implementation), Valuable, Estimatable (with adequate info for meaningful estimation), Small, Testable [INVEST]
    • [Ron Jeffries’ three Cs of user story] Card, Conversation, Confirmation
  • Story Maps
    • are overview of how different user stories are related to each other in the project
  • Features
    • a capabilities / group of functionalities that is of value to the end user
  • Tasks
    • the underlying jobs / development work to fulfill a user story, tasks are taken up by the team members through self-organization
  • Spikes
    • Spike is a short experimental test to help decisions making, e.g. trying a new technology for feasibility study
    • Architectural spikes
      • Architectural Spike is an investigation taken to explore the architectural aspects of the setup
  • Time-boxing
    • time-boxing is a concept for time management by treating time as fixed blocks
    • once the allotted time (time-box) is up, the work must be stopped regardless of whether it has been finished, with fixed start time, fixed end time and fixed duration for the activity to control the risk and progress
    • time-boxing allows the team to focus on the essential works and reduce wastes
  • See Agile planning, monotoring and adapting

Agile Problem solving steps

  • Detecting the problem
  • Identify the problem
  • Pause and reflect on the problem
    • Explore informations
  • Take the problem to the team
    • Create ideas
    • Select the best idea
  • Allow the team to act or not
    • if act, build and test the idea
    • evaluate the results
  • See Agile Problem Solving

Agile Project

Agile Project Artifacts

  • Product Backlog
    • the Product Backlog in an Agile project is a prioritized listing of all features/User Stories for the project, the priority is usually based on the perceived value of the customer
      • the Product Backlog is to be created and updated by the Product Owner
      • grooming (refinement)
        • add items based on new User Stories and delete old items by considering the relative values of all tasks
        • Product Backlog should be “Detailed appropriately, Estimable, Emergent, Prioritized (DEEP)”
      • Risk-adjusted backlog
        • the Product Backlog would be re-prioritized with the help of risk analysis input from the team and stakeholders to balance the “risk vs value” factor (as risks are “de-value”)
        • risks are usually considered to be possible negative impacts (though there are many possible positive impacts)
        • See Agile and risk management
  • Iteration Backlog
    • responsible by the team, the iteration backlog contains tasks for the iteration in which tasks are allocated through Self-Organization (team members select the tasks they are most interested in)
  • Burn-down charts
    • Burn-Down Chart is a chart showing tasks remaining (in story points, etc.) over the project life
  • Burn-up charts
  • Kanban boards
    • Kanban Board is a task board showing the progress of tasks through the project processes, can be tailor-made to suit individual projects
    • a WIP limit (work-in-progress) would be enforced to ensure efficiency
      • WIP means “Work In Process” – a work that has been started but not yet reach “done”
      • WIP can also be considered to be the size of the job queue
  • Cumulative flow diagrams
    • Cumulative Flow Diagram (CFD) is a chart showing the state of all tasks through the project processes
    • a widening band indicates “Agile smells” and would need investigation to tackle the issues of a particular process
    • Little’s Law
      • cycle time is proportional to the size of queue (WIP)
      • cycle time
        • the time from the very beginning of a task to reaching done status
        • larger WIP would mean longer cycle time
        • a way to improve efficiency is to limit WIP

Agile project management

Agile Project Management Fundamentals

Agile project management model

  • Jim Highsmith’s agile project management model consists of the following five phases: Envisioning, speculating, exploring, adapting, and closing. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
  • We apply empirical process control where underlying mechanisms are not well defined.
  • Agile project management differs fundamentally from traditional project management in the following ways : High-level project scope, multiple iterations of product development, teams are self-organizing, extensive customer involvement. [Manifesto for Agile Software Development. Agile Alliance.]
  • Key characteristics of agile project management include : continuous improvement, cross-functional teams, short iterations, an incremental approach, and business priorities and customer value. [The Art of Agile Development. James Shore.]
  • Jim Highsmith’s agile project management model consists of the following sequential five phases : Envisioning, speculating, exploring, adapting, and closing. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Agile project management phases

  • Envisioning
    • The focus in the envisioning phase is on project vision, scope (and requirements), project schedule, and assembling a project team. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
  • Speculating
    • The focus in the speculation phase is on estimating iteration and release plans, defining feature breakdown, developing a rough project plan, considering project risk and risk mitigation strategies, and estimating project costs. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
  • Exploring
    • When conducting the exploring phase, project leaders assist developers by removing any obstacles or constraints that my impeded progress, and managing interaction with product owners, customers, and other stakeholders. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
    • In the exploring phase, the agile team focuses on designing, building, and testing product features. This occurs within useful increments to the customer. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
  • Adapting
    • In the adapting phase, the agile team encourages feedback of the latest deliverable of an iteration.
    • From the feedback, the team adapts product features and plans for the subsequent iteration.
    • In the adapting phase, the agile team leader may make adjustments to the team makeup, like problems raised by team members, if any team dynamic problems arise.
    • [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]
  • Closing
    • In the closing phase, the agile team completes all remaining project work.
    • In a software project, remaining work can be such tasks as user training documentation and installation manuals.
    • [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Agile Release Train

  • An agile release train is an approach to aligning the vision, planning and dependencies of multiple teams by providing cross-team synchronization.
  • See Team and Technical Agility

Agile Sizing and Estimation

  • Make use of progressive elaboration to estimate project efforts more accurately.
    • Update the team capacity to factor in maintenance and operations demands.
  • At the very beginning of the project, make initial rough estimate ranges on scope, schedule and cost based on the high level requirements to kick off the project.
    • The initial estimates must be refined to provide more accurate figures based latest understanding of the project.
    • As the project (team velocity, scope, etc.) changes, the estimates must be updated continually.
  • See Agile estimation

Agile smells

  • Agile term for “symptoms of a problem”, they are signs that the Agile project is not running properly and problems are in the making

Agile Testing

Agile Themes

  • a theme is usually assigned for an iteration in which similar functions are grouped to be done in a batch to maintain focus of the team, e.g. bug fix, reporting, etc.

Agile triangle

  • The agile triangle includes value, quality, and constraints as its parameters.
  • [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Agile Unified Process (AUP)

  • Agile Unified Process (AUP) is a simplified version of the Unified Process, or Unified Process (UP) (Unified Process (UP) itself is a more detailed framework for iterative and incremental software development).
    • Agile Unified Process (AUP) simplifies UP for the agile framework.
    • Agile Unified Process (AUP) projects use four phases :
      • inception,
      • elaboration,
      • construction,
      • transition.
    • At the end of each short iteration, the team delivers a working product.
    • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Agile variance and trend analysis

  • A variance is the difference between an actual result and an expected result.
  • The process by which the total difference between standard and actual results is analysed is known as variance analysis.
    • When actual results are better than the expected results, we have a favourable variance (F).
    • If, on the other hand, actual results are worse than expected results, we have an adverse variance (A).
  • See Agile variance and trend analysis

Agile Vendor management approach

  • The Agile Manifesto values customer collaboration over contract negotiation which sets an important tone for procurement relationships on agile projects.
    • The Agile Manifesto sets forth the idea that a buyer and seller work together to create products and governs the entire procurement process.

Agile Works

  • Completing remaining project work
  • Authoring user documentation
  • Authoring product release instructions

Agility

  • “Agility is the ability to adapt and respond to change … agile organizations view change as an opportunity, not a threat.” —Jim Highsmith

ALM (Application Lifecycle Management)

  • Application Lifecycle Management (ALM) is a holistic view on the management of software applications and systems, accounting for all stages of the existence of a software product.
    • Designed for the execution of a software delivery project, Application Lifecycle Management solutions coordinate people, processes, and tools in an iterative cycle of integrated software development activities.
    • Application Lifecycle Management includes
      • Planning and change management
      • Requirements definition and management
      • Architecture management
      • Software configuration management
      • Build and deployment automation
      • Quality management

Application Lifecycle Management (ALM)

  • Application Lifecycle Management (ALM) is a holistic view on the management of software applications and systems, accounting for all stages of the existence of a software product.
    • Designed for the execution of a software delivery project, Application Lifecycle Management solutions coordinate people, processes, and tools in an iterative cycle of integrated software development activities.
    • Application Lifecycle Management includes
      • Planning and change management
      • Requirements definition and management
      • Architecture management
      • Software configuration management
      • Build and deployment automation
      • Quality management

Approved Iterations

  • After the time assigned to an iteration has been used up, the team will hold a review meeting with the stakeholders (mainly management and customers) to demonstrate the working increments from the iteration.
  • If stakeholders approve the product increment against the backlog selected for the iteration, the iteration is said to be approved.
  • Approved iterations may be used in the contract of work as a way to structure the release of partial payment to the contractor.

Architectural spike

Asset

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

ATDD (Acceptance Test Driven Development)

  • Acceptance Test Driven Development (ATDD) Tests should be readable and focused for customers.
  • Acceptance Test Driven Development (ATDD) is a test-first software development practice in which acceptance criteria for new functionality are created as automated tests.
    • The failing tests are constructed to pass as development proceeds and acceptance criteria are met.
  • Acceptance Test Driven Development (ATDD) is the practice of expressing requirements as acceptance tests.
  • Acceptance Test Driven Development (ATDD) focus on capturing requirements in acceptance criteria and use to drive the development. ATDD technique encourages bringing the customer in design phase.
  • ATDD helps reducing the defects in code.
    • However it does not reduce the defects completely.
  • Advanced practices of test-driven development can lead to Acceptance Test-driven development (ATDD) where the criteria specified by the customer are automated into acceptance tests, which then drive the traditional unit test-driven development (UTDD) process.
  • Acceptance Test Driven Development (ATDD) is similar to Test Driven Development (TDD) in that it requires programmers to create tests first before any product code.
    • The tests in Acceptance Test Driven Development (ATDD) are aimed at confirming features/behaviors that the intended software will have.
    • The iterative cycle of Acceptance Test Driven Development (ATDD) with its four steps can be remembered as the four Ds : 1) Discuss, 2) Distill, 3) Develop, and 4) Demo.
      • 1) Discuss:
        • The agile team and customer or business stakeholder discuss a User Story in detail.
        • Talking about the expected behaviors the User Story should have and what it should not.
      • 2) Distill :
        • The Developers takes those items learned from the discussion and distills them into tests that will verify and validate those behaviors.
        • The distillation process is where the entire team should have a good understanding of what « done » (or completed, see Definition of Done (DoD)) means for a User Story.
        • That is, what the acceptance criteria are.
      • 3) Develop :
        • After distillation, the team develops the test code and product code to implement the product features.
      • 4) Demo :
        • Once the product features have been developed, the team demonstrates them to the customer or business stakeholders for feedback.
    • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Architectural Spike

Automated Tests :

Automation

  • Automation is important because it provides rapid assurance that defects and configuration management issues have not been introduced.
  • See Application Lifecycle Management

Batch size

  • One of the key differences in Agile software development as opposed to a more traditional approach is that Agile favours small batches.
    • This concept has however been embedded into the practises rather than made an explicit one.
    • The most obvious place we see this is in the short timescales imposed on iterations.
    • When Scrum was first codified it advocated Sprints no longer than one calendar month.
  • Our industry has shortened this even further as we seem to be standardising on two weeks.
    • This combined with an emphasis on working software creates a small batch approach to developing and releasing products.
    • This allows for shorter feedback cycles and many other benefits.
  • The one which is less well understood and derives from the manufacturing world, is that small batches reduce variability.
    • Variability is usually felt in our low predictability but has knock on effects on quality and efficiency.
    • The longer it takes to complete something, the more likely that we will experience quality issues.
  • From this manufacturing paradigm we now understand that there is a mathematical relationship between batch size and variability.
    • Donald Reinertsen describes big batches as a snake swallowing an elephant.
    • What is clear is that if we mean to improve our predictability, we must reduce batch size accordingly.
    • In Product Owner terms this means that the size of features and stories need to be trimmed to the minimum.
      • Think “Small is beautiful” when you are splitting stories.

BDD (Behavior Driven Development)

Behavioral design patterns

  • In software engineering, behavioral design patterns are design patterns that identify common communication patterns among objects.

Behavior Driven Development (BDD)

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.

Blitz planning

  • Blitz planning incorporates story dependencies and involves using cards to plan a project where timeline, tasks, and story dependencies are identified and considered. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Brainstorming

  • Brainstorming is a technique to help identify opinions, solve issues, & improve processes.
    • everyone can voice out their opinions freely without immediate judgement
  • In Agile projects brainstorming sessions are mostly held around :
    • Product roles & personas
    • Minimal marketable features for release
    • Potential risks
  • 3 models : Quiet writing/Round-Robin/Free
    • Quiet brainstorming is a silent brainstorm is a technique for generating ideas while everyone remains quiet.
      • This allows participants to think without distractions or influence from other members of the group, and helps combat problems with groupthink and social loafing common to traditional brainstorming sessions.
    • Round-Robin Brainstorming is about getting everyone involved.
      • Every team member gets the opportunity to generate ideas, without being influenced by other people.
      • The ideas of others are used by every team member to generate more ideas, without being influenced by the assertiveness or dominance of other team members.
    • Free-form / Popcorn Brainstorming is a simple tool for groups in which everyone is comfortable speaking out.
      • You just open the floor for ideas and take them as they come.
      • Summarize ideas as necessary and record them on a flip chart.

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.]

Branching

Bug

  • A software bug is an error, flaw, failure, or fault that produces an incorrect or unexpected result.

Bugs Report

Build

  • Basically, Build is the process of creating the application program for a software release, by taking all the relevant source code files and compiling them and then creating a build artefact, such as binaries or executable program, etc.
    • How often should the build be executed?
      • Whenever new or changed code is checked into version control.
  • Automated Software Build Development supports continuous integration
  • See Application Lifecycle Management

Build Scripts

  • Build scripts are small programs that automate the aggregation of all system components into deployment packages.

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-down chart

  • Burn-Down Chart is a chart showing tasks remaining (in story points, etc.) over the project life
  • A Burn-Down Chart is a plot of work remaining to reach a given goal on the vertical axis, and time on the horizontal axis.
    • Each point on the chart shows how much work was left to do at the end of that day (or week, month or other time period).
    • Regular review of progress charts such as burndown charts or Burn-Up Charts for the project you are managing can immediately identify problems and allow you to control them early.
    • Identifying problems early and highlighting corrective action you have taken will impress your clients and gain you their confidence and trust.
  • More at Burn-Down Chart

Burn rate

  • a measure of how fast money is burnt / the amount of cost estimated over a given period of time (e.g. $1000 per day)

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

Burn-up chart

  • Burn-Up Chart is a chart showing tasks completed (in story points, etc.) over the project life
    • preferred to burn-down charts as scope changes are clearly visible in burn-up charts
  • A Burn-Up Chart, or burnup chart, tracks progress towards a projects completion.
    • In the simplest form of Burn-Up Chart there are two lines on the chart:
      • A total work line (the project scope line)
      • A work completed line
  • Burn-Up Chart
    • The vertical axis is amount of work, and is measured in units customized to your own project.
      • Some common units are number of tasks, estimated hours or story points (in agile project management methodologies).
    • The horizontal axis is time, usually measured in days.
  • More at Burn-Up Chart

Business Case

  • Business Case is a necessary entries to the Project Charter
  • Business Case :
    • PROJECT OVERVIEW
    • ANTICIPATED COSTS
    • ANTICIPATED BENEFITS
    • BUSINESS MODEL & INDEXES
    • ROI ASSUMPTIONS & RISKS
    • SWOT/PEST
      • Strenght, Weakness, Opportunity, Threat
      • Political, Economic, Social, Technological
    • RECOMMENDATIONS
    • Risks of not undertaking the project
  • See Agile analysis and design

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.]
  • See Agile analysis and design

Business Owner

Business value delivered chart

  • The entire enterprise (business, management, and development teams) needs the line of sight to velocity (points/time) dashboard-type view of work management which in other terms is a business value delivered chart.

Cadence

  • Cadence refers to how often something is scheduled or occurs.
    • Think of it as a way to keep in “rhythm” with your teams.

Candidate Use Cases

  • Candidates use cases include the actors, the goals of each of those actors and a narrative paragraph describing the process through which the actor achieves the goal by interacting with the system under discussion.
    • They are called candidate use cases because further analysis is probably going to change the list by merging splitting, adding and deleting use cases.

Capacity

  • Capacity represents the amount of work that can be completed within a certain time frame and is based on the number of hours that an individual or team will be available to complete the work.
    • How it’s Used:
      • The Product Owner and Agile team determine the capacity or amount of workload, they can take on for an upcoming sprint.
      • The capacity is decided during the Sprint Planning meeting.
    • Project Management Benefits:
      • Improves resource management.
      • Estimates the completion of a project.

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.

CARVER

  • (Criticality, Accessibility, Return, Vulnerability, Effect, and Recognizability) relative to the objective and mission of the project

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.]

Change report

  • A change report is typically authored after a Sprint has completed. [Agile Project Management with Scrum. Ken Schwaber.]

Chartering

  • The technique of chartering agile projects has the same general goal as the Develop Project Charter Process defined in the PMBok guide.
    • However Agile projects have less detail than non-agile charters and focus more on how the projects will be run than on exactly what will be built.
    • On a dynamic project with a moving target a high degree of planning may be inappropriate because key elements of the project are likely to change.
  • Chartering involves creating a project charter, which can last from a few days to a few weeks.
    • Chartering consists of four activities :
      • Building the core project team,
      • performing an Exploratory 360° assessment,
        • The executive sponsor conducts the Exploratory 360° assessment to assess the business case of the project.
        • Several dimensions are explored: business value, requirements, domain area, and technology impacts.
        • Based on the results the team adjusts the Crystal methodology to the need or, in some cases, the project may be cancelled if serious issues are discovered.
      • fine tuning the methodology,
      • building the initial project plan.
    • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
  • In the eXtreme Programming (XP) framework, the best role for a Customer is to write well-defined User Stories. [User Stories Applied: For Agile Software Development. Mike Cohn.]
  • See Agile analysis and design

Chickens and Pigs

  • Definition:
    • The terms “Chicken” and “Pig” come from “The Chicken and Pig Story” by Ken Schwaber, a software Developer who helped formulate the initial version of Scrum.
      • Most often used in Scrum, a “Chicken” refers to someone who is involved in the project, but is not accountable for any specific deliverable (such as a stakeholder or manager).
      • On the other hand, a “Pig” is someone who is committed and directly accountable for deliverables.
    • “The Chicken and Pig Story” by Ken Schwaber
      • A pig and a chicken are walking down a road.
      • The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?”
      • The pig looks back at the chicken and says, “Good idea, what do you want to call it?”
      • The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs?’”
      • “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.”
    • How it’s Used:
      • Chickens and Pigs are used to define participants and roles in Scrum.
      • “Pig” roles are usually the actual Developers, the Scrum Master, and the Product Owner.
      • “Chicken” roles are managers or stakeholders.
    • Project Management Benefits:
      • Clarifies and defines roles.
      • Sets projects expectations.
      • Promotes accountabilities.

Class Coupling

  • It is a code quality metric.
  • Class coupling is a measure of the dependencies a class has on other classes.
    • A measure of how many classes a single class uses.
    • Class coupling measures each class only once for this metric no matter how many times it gets used.
  • See Class Coupling and Cohesion

Clean code

Clean code principles

Coaching & mentoring

  • Coaching & mentoring agile teams helps them keep on track, over come issues & continually improve their skills.
    • Is done simultaneously on 2 levels individual & team level.
      • Where team coaching will most of the time be done on iteration boundaries when we have the team assembled for planning, reviews & retrospectives.
      • During iteration we provide mostly individual coaching.
  • Individual coaching :
    • Meet them halfway
      • don’t push people directly to the end-point, guide them to a certain point beyond the difficulty and let them decide from there
    • Guarantee safety
      • keep conversations confidential
    • Partner with managers
      • the agile approach can not be consistent with the functional management so the agile coach has also to align functional management to the issue
    • Create positive regard

Code Coverage

  • Code Coverage is a code quality metric.
  • Code Coverage is a measure used to describe the degree to which the source code of a program is executed or exercised when a particular test suite runs.
    • Code Coverage is a measure which describes the degree of which the source code of the program has been tested.
    • It is one form of white box testing which finds the areas of the program which have been exercised by a set of test cases.
      • Note that 100% coverage will not assert that the quality is perfect, but a low number will tell you that you have insufficient testing and the source code is error‐prone.
      • In addition, for Code Coverage calculation all unit tests should be passed.

Coding Principles

  • Application Architecture Cross – Cutting concerns (concerns across different layers / modules / classes within the application) should also be addressed.
  • Example of some concerns are:
    • Performance & Scalability
    • Layering/partitioning Quality and validation
    • Reusability, Reliability, Availability, Serviceability, and Performance
    • Concurrency
    • Security
    • Maintenance
    • Error Handling
    • Logging
    • Caching and Transaction Management
  • See Scrum and Coding Principles

Code Library

  • The code library manages all of the code in the solution.
    • This is generally some form of source code control repository such as Team Foundation Server (TFS) or CVS.

Cohesion

  • Cohesion is a measure of the degree to which the responsibilities of a single module or a component form a meaningful unit.
    • Cohesion describes how related the functions within a single module are.
    • High is better.
  • Cohesion makes software easier to understand, reduces the effects a change on one part of the system has on the rest of the system, and it allows us to reuse code within our application.
  • See :

Collaboration

  • Collaboration is a key soft skill negotiation skill.
    • It involves working in groups to create ideas, solve problems, and produce solutions.
    • [Coaching Agile Teams. Lyssa Adkins.]
  • Pair programming is an effective method for improving team collaboration. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Collaboration with customer

  • Because agile emphasizes customer collaboration, the team should simply collaborate with the customer to clarify the User Story. [User Stories Applied: For Agile Software Development. Mike Cohn.]

Collective Code Ownership
A software development principle popularized by eXtreme Programming (XP) holding that all contributors to a given code base are jointly responsible for the code in its entirety.

Collocated teams and distributed teams

  • A high-performance agile team is one that is ideally collocated for osmotic communication and face-to-face interaction.
    • However, collocation isn’t always feasible in today’s multinational environment.
    • For distributed teams, several practices are available to provide the best form of effective communication in the absence of being collocated: team intranet sites, virtual team rooms, and video conferencing over e-mail when possible.
    • Geographic separation, especially on a world-wide scale, causes the team to consider language and cultural differences, and time zone differences.
    • [The Art of Agile Development. James Shore.]
  • See The Scrum framework : Scrum Self-Organization

Commitment

  • Without the commitment of Scrum Master, Product Owner, and the Developers, there is no possibility to deliver outstanding results with software.
    • In the world of the scrum software development process, most people translate the commitment value as the agreement and confinement of goals of given sprint deliverables.
    • Although this entirely makes sense, that understanding is not flawless.
    • Whenever you hear the word “commitment” within the context of Scrum Values; what you should remember is the word: “obsession”.
    • To be successful in software engineering and, in life and business, you should become obsessed with your goals.
    • So in the context of the scrum process, you should become obsessed with creating marvelous software for your clients to solve their problems.
  • Why are commitment and the associated obsession with Scrum goals so important?
    • Because without the obsession with the team’s mission to build and deliver astonishing software, each time the Scrum Team encounters a non-trivial impediment, your work will slow down and stall.
    • Then the Scrum Master and the Scrum Team will start creating explanations to justify and legitimize for Product Owner why they’re unable to deliver Sprint goals.
    • Excuses should have no more room in your team if your goal is to become a better than an average Scrum Team.
  • Only with an enormously high level of dedication, it’s relatively more comfortable and fulfilling to solve the problems of our clients and help and build value for them with software.

Communication tooling

  • these are tools to promote more effective communication
    • e.g. reduce roadblocks for collecting, maintaining and disseminating information
  • types : low-tech high-touch tools, digital tools
    • low-tech high-touch tools are preferred because these tools can promote collaboration and communication and everyone knows how to participate
      • Examples :
        • co-located teams :
          • war room and/or a dedicated conference room
            • walls filled with information radiators like whiteboards, billboards, post-its, charts, task boards, etc.
        • distributed teams :
          • virtual shared space using digital tools
            • wikis website, instant messaging – Skype, web conferencing, etc., online planning poker – an estimation tool of user stories, card meeting – a brainstorming session using 3×5 index cards, version control – a tool for version control for configuration management, e.g. CVS, CASE tools : reverse engineering tools to generate codes from designs, other Agile tools for building/configuring/deploying deliverables
  • See Agile communications

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.]

Compliance (organization)

  • 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.]
  • Compliance is conforming to a rule, such as a specification, policy, standard or law (e.g. regulatory compliance)
    • compliance usually requires documentation, which is somewhat against the principles of agile (working software over documentation)
    • a balance has to be struck (maybe with the help of Agile compliance management systems)

Conflict

  • Conflicts are unavoidable in the project environment.
    • Conflict resolution must not focus on personalities and past events.
    • The people who are in conflict are first responsible for resolving it.
    • Conflict resolution is a key soft skill negotiation skill.
    • It involves applying proper leadership techniques to resolve and diffuse any conflict between team members or other stakeholders.
    • [Coaching Agile Teams. Lyssa Adkins.]
  • There are 5 stages of conflict, in the order of light to severe :
    • A Problem to solve
      • a problem occur or is presented
    • Disagreement
      • everyone tries to protect their own interests
    • Contest
      • people begin taking sides (a you vs me situation)
    • Crusade
      • people in conflict will make over-generalization in judgement, not just about the problem but also about the persons
    • World War
      • the problem is now unresolvable, either one side will survive
  • It is advisable to try to resolve conflicts early in the stage to reach a consensus with effective conflict resolution strategies:
    • Confronting – open dialogue (everyone is able to voice out their opinions) leading to problem resolution to create a win-win situation
    • Collaboration – working together to reach mutually agreed solution

Conflict Resolution

  • conflict is inevitable and is good for project success when controlled
    • focusing on turning conflicts into a win-win situation, often need to make use of emotional intelligence and active listening
    • Conflict is an inevitable part of project work.
    • Whenever people come together to solve problems, there will be differences of opinion and competing interests.
  • conflict resolution tactics :
    • Accommodation
      • identify points of agreements and play down disagreement
    • Avoidance
      • ignore the conflict
    • Compromise
      • both sides to give up something, a lose-lose situation
    • Forcing
      • force one side to accept something, a win-lose situation
    • Confronting
      • open dialogue leading to problem resolution, a win-win situation
    • Collaboration
      • work together for mutually consented solution

Continuous Delivery (Release on Demand)

  • Continuous Delivery is a software delivery practice similar to Continuous Deployment (CD) except a human action is required to promote changes into a subsequent environment along the pipeline.
    • Continuous Delivery is the aim of keeping the system “Production Ready” during development to enable the release of a product to the end user on demand.

Continuous Deployment

  • Continuous Deployment (CD) is deploying every change into production automatically.
    • Continuous Deployment (CD) is a software delivery practice in which the release process is fully automated in order to have changes promoted to the production environment with no human intervention.


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 improvement with the Deming’s PDCA Cycle (plan – do – check -act)
    • make use of process improvement and self-assessment for improved product
    • e.g. code refactoring and pair programming
  • Definition:
    • Continuous improvement is a process of improving quality and efficiency by making small, incremental changes over time.
    • In Kanban, continuous improvement refers specifically to the process of optimizing workflow and reducing cycle time, resulting in increased productivity.
    • Also Known As: Kaizen
  • How It’s Used:
    • Continuous improvement is used to introduce improvement into the work process on an incremental basis and involves the following steps:
      • 1) Identify,
      • 2) Plan,
      • 3) Execute, and
      • 4) Review.
    • More specifically for Kanban, there are no set due dates so the team focuses on work-in-progress.
      • As team members collaborate to troubleshoot problems and brainstorm new ideas, the process becomes more efficient and streamlined, cycle times decrease, and workflow is optimized.
      • Teams do not need to be cross-functional in Kanban.
  • Project Management Benefits:
    • Improves productivity and delivery.
    • Increases accuracy in forecasting future work and delivery.
    • Streamlines work and reduces waste.
    • Introduces improvement on an incremental basis.
    • Increases a sense of pride and accomplishment in team members.
  • see Continuous Learning Culture

Continuous Integration

  • Continuous Integration (CI) is 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)
    • The eXtreme Programming (XP) principle of Continuous Integration (CI) is that code is integrated into the full code base as soon as it is built, tested, and completed.
      • Once integrated, the code base and therefore the entire system is built and tested.
      • Continuous Integration (CI) is just one principle of eXtreme Programming (XP) that promotes rapid delivery of software and the early detection of integration defects.
      • [The Art of Agile Development. James Shore.]
    • An eXtreme Programming (XP) project typically integrates code at least once per day. [The Art of Agile Development. James Shore.]
    • Being continuously integrated theoretically means having a working product ready to ship at any time.
    • [The Art of Agile Development. James Shore.]
  • Continuous Integration (CI) [usually for IT projects] to continuously integrate changes (usually in small trunks) to the codebase by merging the new codes as soon as practicable (i.e. once ready)
    • to avoid code conflicts and minimize risks of incompabitility
    • on every integration, the codebase needs to be tested (usually by Unit Testing (UT) with automated testing tools / Regression Testing tools)
    • typical setup for continuous integration :
      • A source code repository
      • A check-out and check-in process
      • An automated build process (compiles codes, runs tests and deploys)
    • if errors are found, fixing the broken build is of top priority
  • Project Management Benefits:
    • Enables rapid feedback, so that defects can be identified and corrected quickly.
    • Minimizes time and effort needed to perform each integration.
    • Provides an automated build and release process.
    • Allows software to be deliverable at any moment.

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.]

Continuous planning

  • Progressive elaboration is continuous planning with the expectation that project plans and details will change but become more refined as the project progresses. [Agile Estimating and Planning. Mike Cohn.]

Cost Performance Index (CPI)

  • Cost Performance Index is a measure of project progress from a cost perspective used in earned value management (EVM).
  • 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)

Coupling and Cohesion

  • In software engineering, coupling is the degree of interdependence between software modules;
    • a measure of how closely connected two routines or modules are;
    • the strength of the relationships between modules.
  • Coupling is usually contrasted with Cohesion.
    • Low coupling often correlates with high Cohesion, and vice versa.
    • Low coupling is often thought to be a sign of a well-structured computer system and a good design, and when combined with high Cohesion, supports the general goals of high readability and maintainability.
  • See :

Courage

  • There are times when doing the correct thing to serve the best values and benefits for our clients are not the easiest :
    • In such moments, Scrum Master, Product Owner, and the Developers should remember their duty and obligation.
      • That’s to build the best possible products and services in their particular business and information technology domain.
      • To be better than mediocre, a Scrum Team should sooner or later face difficult decisions that won’t make everyone happy in their particular ecosystem of Stakeholders.
      • To deal with this, all members of the Scrum Team should remember what they learned with the Scrum framework.
    • They should remember to be courageous, and they should master to decide and act courageously.

Creational design patterns

  • In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation.
    • The basic form of object creation could result in design problems or in added complexity to the design.
    • Creational design patterns solve this problem by somehow controlling this object creation.
      • Creational design patterns are composed of two dominant ideas.
        • One is encapsulating knowledge about which concrete classes the system uses.
        • Another is hiding how instances of these concrete classes are created and combined.
      • Creational design patterns are further categorized into object
        • Creational patterns and Class-creational patterns, where Object-creational patterns deal with Object creation and Class-creational patterns deal with Class-instantiation.
        • In greater details, Object-creational patterns defer part of its object creation to another object, while Class-creational patterns defer its object creation to subclasses.
    • See Scrum and Software Development Practices

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.

Critical Thinking

  • A process in which one applies observation, analysis, inference, reflective thinking, and the like, in order to reach judgments.
    • Such judgements should be open to alternatives that may not normally be otherwise considered.

Cross-functional Team

  • a group of people with different functional expertise working together toward a common goal
    • Usually a cross-functional team includes people from not only different departments (marketing, design, development), but also different levels of an organization.
      • often function as self-directed teams
      • members must be well versed in multi-tasking as they are simultaneously responsible for various functions
  • See Scrum Team, Accountability, Empowerment and Self-organization

Crystal Clear

  • Regardless of color, the Crystal framework is cyclical and has three fundamental processes: chartering, delivery cycles, and wrap-up.
    • Crystal chartering includes building the team, doing an Exploratory 360, defining standards of practice for the team, and building the project plan.
    • In the delivery cycle, the crystal team iteratively develops, integrates, tests, and releases the product in iterations that last from one week to two months.
      • Like other agile frameworks, crystal includes collaborative events, like stand-up meetings and reflective improvement workshops.
    • In wrap-up the team concludes the project and holds a completion ritual where the team reflects on the entire project.
    • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Crystal Life cycle

  • The Crystal development process is cyclical/iterative.
    • Its primary components are chartering, delivery cycles, and project wrap-up.

Crystal methodologies

  • Crystal methodologies is a family of methodologies for a flexible and lightweight approach to software development.
    • The family of methodologies is color coded to differentiate its members (e.g., clear, yellow, orange, red.), the color chosen depends on the level of effort required.
    • On one end of the spectrum is crystal clear, which is for smaller efforts, while crystal red is for larger efforts.

Crystal properties

  • Frequent delivery of useable code
  • Reflective improvement
  • Osmotic communication
  • Personal safety
  • Focus
  • Easy access to expert users
  • Technical environment with automated tests, configuration management, and frequent integration
  • See Crystal methodologies

Cumulative Flow Diagram (CFD)

  • Cumulative Flow Diagrams (CFD) is a chart showing the state of all tasks through the project processes
  • A diagram used by Kanban is the Cumulative Flow Diagram (CFD), which describes the overall flow through the Kanban system; it provides a measurement for every significant step in the workflow.
    • Like Burn-Up Charts , cumulative flow diagrams are information radiators that can track progress for agile projects.
    • Cumulative Flow Diagrams (CFD) differ from traditional Burn-Up Charts because they convey total scope (not started, started, completed) of the entire backlog.
    • Tracked items can be features, stories, tasks, or use cases.
    • By tracking total scope, Cumulative Flow Diagrams (CFD) communicate absolute progress and give a proportional sense of project progress (e.g., On Day 14: 15% of features have been completed; 15% have been started; and, 70% have not been started). [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
  • 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
    • a widening band indicates “Agile smells” and would need investigation to tackle the issues of a particular process
    • Little’s Law – cycle time is proportional to the size of queue (WIP)
      • cycle time – the time from the very beginning of a task to reaching done status
      • larger WIP would mean longer cycle time
      • a way to improve efficiency is to limit WIP
  • They help us to gain inside in to projects issues, bottlenecks & cycle times
  • 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.]
  • This tool can also be used to confirm value at the end of each iteration and remaining development is aligned to the target.
    • They serve as important checkpoints in AGILE projects.
      • New evolving priorities are then captured in the user story backlog.
      • Projects that do not engage in customer-valued prioritization are likely to miss out on identifying critical success factors
  • Customer-value prioritization principles :
    • deliver the highest value to the customers as early as possible
    • the Product Backlog should be customer-valued prioritized while taking into accounts technical feasibilities, risks, dependencies, etc. in order to win customer support

Customized Contracts

  • Contracts can be pieced together to create a customized or hybrid contract that benefits both the customer & the seller.
  • On AGILE contracts procurement has always been particularly challenging, since the scope is not fully determined early.
    • Degree of success is most of the time established when parties continue on future collaboration
  • See Agile vendor management and contracts

Cycle time

  • Cycle time is the amount of elapsed time between when a work item starts and when a work item finishes.
    • Cycle time is the amount of time for a feature from start (entering into the product backlog) to finish (done), the shorter the cycle time, the better
  • Cycle time clock starts when work begins on the request (To Do), and ends when the item is delivered.
    • Cycle time is a more mechanical measure of process capability.
    • Cycle time is the time between two successive deliveries.
  • Example
    • In our case it is the time between two User Stories entering the last stage– Deployed stage
    • In this case, User Story 34 enters the Deployed stage on day 11, then two days after, the next story– User Story 37–enters the Deployed stage;
    • Cycle time equals 2 days (day 13 – day 11).
  • How to calculate Cycle time
    • Total Cycle Time = Number of things in process /Average Completion Rate
    • Example:
      • Average Completion Rate = 4, Number of things in process = 8,
      • Cycle Time = 8 Items / 4 per week
      • Cycle Time = 2 weeks
  • See Agile cycle time and lead time and Scrum and Kanban

Cycle Time and Throughput

  • Cycle time is the time necessary to get a single item of work done from start (idea) to finish (as a shippable product that delivers value)
    • Cycle time can be reduced by shortening iteration time (breaking down task sizes), limiting Work In Progress and reducing wastes
  • Throughput is the number of things that can be done in an iteration
  • Cycle Time = WIP / Throughput
    • Defect cycle time is the time between defect injection and defect remediation, the shorter the defect cycle time the better

Cyclomatic Complexity definition

  • Cyclomatic Complexity is a Code Metric.
  • Cyclomatic Complexity :
    • Measures the number of linearly independent paths through a program’s source code.
    • Cyclomatic Complexity represents the number of unique paths through your code
      • Code complexity measure based on the # of independent logical branches through a code base.
      • The number of “if” statements, loops and switch cases in a code is represented by Cyclomatic complexity.
    • Cyclomatic Complexity is expressed as a simple integer.

Daily Scrum

  • A Daily Scrum is typically held in the morning and helps Developers set the context for all of the work that is to be completed that day.

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.

Debt

Debt types

  • Incremental Debt :
    • Caused by repeating the above without any work to reduce the debt
  • Inadvertent debt:
    • This is typically caused by a lack of awareness or knowledge
  • Strategic Debt :
    • Debt caused to gain strategic benefits (such as time to market)
  • Tactical debt:
    • Short-time gains, for instance cutting some corners to make an extra release for increased customer satisfaction
  • Technical Debt :
    • A Technical debt represents results which are a consequence of poor technical choices.
  • See :

DEEP

  • Product Backlog should be “Detailed appropriately, Estimable, Emergent, Prioritized (DEEP)”

Defects

Defect Log

Definition of Done (DoD)

  • A definition of done refers to when a scrum team has consistent acceptance criteria across all users stories.
    • This helps determine when a user story has been completed.
  • A cornerstone of the Scrum framework in agile is to ‘always have a product that you could theoretically ship,’ it is important for the team and Product Owner to have a Definition of Done (DoD) or what criteria is necessary to consider user features or functionality in a state of finality. [Coaching Agile Teams. Lyssa Adkins.]
    • Done usually means the feature is 100% complete (including all the way from analysis, design, coding to user acceptance testing and delivery & documentation) and ready for production (shippable)
    • Done for a feature :
      • feature/backlog item completed
    • Done for a Sprint :
      • work for a sprint completed
    • Done for a release :
      • features shippable
    • The exact definition of done has been be agreed upon by the whole team (Developers, Product Owner / customer, sponsor, etc.)
  • In a Task board the ‘done’ column holds tasks that have been completely developed, tested or verified, and integrated into the product and require no further attention.
    • The ‘done’ column should not hold incomplete tasks, but ones that are truly completed. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
  • Done means the feature is 100% complete according to pre-agreed conditions (e.g. including all the way from analysis, design, coding to user acceptance testing and delivery & documentation) and ready for production (shippable)
  • Done :
    • Done for a feature: feature/backlog item completed
    • Done for a sprint: work for a sprint completed
    • Done for a release: features shippable
  • the definition of done (a.k.a. success criteria) must be agreed upon collectively with key stakeholders before carrying out the project works
    • the definition of done will align the expectations of the stakeholders and project team to reduce the risk of wasted work
    • the definition of done includes acceptance criterion and acceptable risks
  • More at Definition of Done (DoD)

Definition of Ready (DoR)

  • Definition of Ready (DoR) establishes a set of criteria (or a checklist) of items which need to be in place before a story can be taken into Sprint Planning.
    • Good examples of what this might contain are:
      • Story estimated at 13 story points or less
      • Story written in User Story format
      • Story has at least the happy path test case written
      • Story has a business value estimate
      • Story has an initial UI (User Interface) sketch mockup (see Sketch, Wireframe, Mockup and Prototype)
      • Constraints on story indicated
    • Establishing a set of “Ready” stories (ideally 1.5 – 2 sprints worth) will help to prevent thrashing in the Product Backlog.
      • It creates a quality benchmark and optimises the flow of stories from the team.
    • The danger is that you might “over-invest” in a story, so the key is to not have too many stories ready to go.
      • The principle of “just enough, just in time” should be respected.
      • Also, this is not a license to start creating spec documents; the intention is still to allow for solutions and requirements to emerge through the process.
      • As a result I advocate a fairly light “definition of ready”; just enough to encourage Product Owners to prepare adequately for Sprint Planning.

Dependency Inversion Principle

  • D – Dependency Inversion Principle. – this principle is primarily concerned with reducing dependencies amongst the code modules.
    • Dependency Inversion principle: Entities must depend on abstractions, not on concretions.
      • It states that the high-level module must not depend on the low-level module, but it should depend on abstractions.
    • See Scrum and Coding Principles

Deployment Scripts

  • Deployment scripts are small programs that automate moving the deployment packages to the desired computing environment.

Depth of inheritance

DSDM Contract

  • This contract focuses on being “fit for business purpose” and passing tests rather than matching all specifications.

Design Comps

  • Design comps provide several alternate design approaches that can be compared in the process of designing the look and feel of the web site.

Design flow

  • Sketches, wireframes, mockups, and prototypes actually represent the different stages of the design flow.
    • They start from low-fidelity and end with high-fidelity respectively.
      • The sketch is the simplest way to present an idea or initiative, even can be drawn in a piece of paper and has a minimum level of fidelity.
      • Wireframe, a low-fidelity way to present a product, can efficiently outline structures and layouts.
      • A mockup looks more like a finished product or prototype, but it is not interactive and not clickable.
      • A Prototype has an interactive attribute and has a maximum level of fidelity and is interactive and clickable.
    • See Scrum and Software Development Practices and Sketch, Wireframe, Mockup and Prototype then Mocks, fakes, and stubs

Design Patterns

  • A Design Pattern is a general, reusable solution to a commonly occurring problem within a given context in software design

DevOps

  • DevOps is an organizational concept that bridges the gap between Development and Operations in terms of :
    • Mindset
    • Skills
    • Practices
    • Silo-Mentality

DevOps and the three Ways

  • First Way : Work always flows in one direction : downstream.
  • Second Way : Create, shorten and amplify feedback loops.
  • Third Way : Continued experimentation, in order to learn from mistakes, and achieve mastery.
  • See DevOps and the three ways

DevOps practices

Distributed teams and Collocated teams

  • A high-performance agile team is one that is ideally collocated for osmotic communication and face-to-face interaction.
    • However, collocation isn’t always feasible in today’s multinational environment.
    • For distributed teams, several practices are available to provide the best form of effective communication in the absence of being collocated: team intranet sites, virtual team rooms, and video conferencing over e-mail when possible.
    • Geographic separation, especially on a world-wide scale, causes the team to consider language and cultural differences, and time zone differences.
    • [The Art of Agile Development. James Shore.]

Documentation

  • Developers are responsible for doing all the required tasks to create a potentially releasable and useful Increment.

DoD (Definition of done)

  • A cornerstone of the Scrum framework in agile is to ‘always have a product that you could theoretically ship,’ it is important for the team and Product Owner to have a Definition of Done (DoD) or what criteria is necessary to consider user features or functionality in a state of finality. [Coaching Agile Teams. Lyssa Adkins.]
  • Definition of Done (DoD), the team makes it into congruence with the Product Owner, and Definition of Done (DoD) is used to keep the meaning of ‘done’ consistent and unambiguous to all.
  • In a Task board the ‘done’ column holds tasks that have been completely developed, tested or verified, and integrated into the product and require no further attention.
    • The ‘done’ column should not hold incomplete tasks, but ones that are truly completed. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
  • Done means the feature is 100% complete according to pre-agreed conditions (e.g. including all the way from analysis, design, coding to user acceptance testing and delivery & documentation) and ready for production (shippable)
  • Done :
    • Done for a feature: feature/backlog item completed
    • Done for a sprint: work for a sprint completed
    • Done for a release: features shippable
  • the definition of done (a.k.a. success criteria) must be agreed upon collectively with key stakeholders before carrying out the project works
    • the definition of done will align the expectations of the stakeholders and project team to reduce the risk of wasted work
    • the definition of done includes acceptance criterion and acceptable risks
  • More at Definition of Done (DoD)

Domain-driven Design

  • Domain-Driven Design (DDD) is the concept that the structure and language of software code (class names, class methods, class variables) should match the business domain.
    • For example, if a software processes loan applications, it might have classes such as Loan Application and Customer, and methods such as Accept, Offer and Withdraw.
    • DDD connects the implementation to an evolving model.
    • Domain-driven design is predicated on the following goals:
      • placing the project’s primary focus on the core domain and domain logic;
      • basing complex designs on a model of the domain;
      • initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
  • See Scrum and Software Development Practices

Domain Specific Language

  • A domain-specific language (DSL) is a computer language specialized to a particular application domain.
    • This is in contrast to a general-purpose language (GPL), which is broadly applicable across domains.

DoR (Definition of Ready)

  • Definition of Ready (DoR) establishes a set of criteria (or a checklist) of items which need to be in place before a story can be taken into Sprint Planning.
    • Good examples of what this might contain are:
      • Story estimated at 13 story points or less
      • Story written in User Story format
      • Story has at least the happy path test case written
      • Story has a business value estimate
      • Story has an initial UI (User Interface) sketch mockup (see Sketch, Wireframe, Mockup and Prototype)
      • Constraints on story indicated
    • Establishing a set of “Ready” stories (ideally 1.5 – 2 sprints worth) will help to prevent thrashing in the Product Backlog.
      • It creates a quality benchmark and optimises the flow of stories from the team.
    • The danger is that you might “over-invest” in a story, so the key is to not have too many stories ready to go.
      • The principle of “just enough, just in time” should be respected.
      • Also, this is not a license to start creating spec documents; the intention is still to allow for solutions and requirements to emerge through the process.
      • As a result I advocate a fairly light “definition of ready”; just enough to encourage Product Owners to prepare adequately for Sprint Planning.

Dreyfus Model

  • The Dreyfus model of skills acquisition by brothers Stuart and Huber Dreyfus covers covers a similar concept as the 3 step Shu-Ha-Ri but uses 5 stages instead from novice to expert.
    • The stages follows a progression from rigid adherence to rules to an intuitive mode of reasoning based ontacit knowledge.
    • The five stages of increasing skill :
      • 1. Novice
        • “rigid adherence to taught rules or plans”
        • no exercise of “discretionary judgment”
      • 2. Advanced beginner
        • limited “situational perception”
        • all aspects of work treated separately with equal importance
      • 3. Competent
        • “coping with crowdedness” (multiple activities, accumulation of information)
        • some perception of actions in relation to goals
        • deliberate planning
        • formulates routines
      • 4. Proficient
        • holistic view of situation
        • prioritizes importance of aspects
        • “perceives deviations from the normal pattern”
        • employs maxims for guidance, with meanings that adapt to the situation at hand
      • 5. Expert
        • transcends reliance on rules, guidelines, and maxims
        • “intuitive grasp of situations based on deep, tacit understanding”
        • has “vision of what is possible”
        • uses “analytical approaches” in new situations or in case of problems

DRY Principle

  • Dry refers to the existence of minimum duplication in a code.
  • DRY is the principle to avoid repetition of the same information in one system, preventing the same code from being produced multiple times on code base.
  • Don’t repeat yourself (DRY) is a principle of software development aimed at reducing repetition and duplication of software codes.
  • Don’t repeat yourself (DRY, or sometimes Do not Repeat Yourself) is a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.
  • The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”.
    • The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer.
  • See Scrum and Coding Principles

DSDM (Dynamic Systems Development Method)

Dynamic Analysis :

  • Dynamic Analysis is executed while a program is in operation.
    • A dynamic test will monitor system memory, functional behavior, response time, and overall performance of the system.
    • On the other hand, Static Analysis is performed in a non-runtime environment.
    • Typically, a Static Analysis tool will inspect program code for all possible run-time behaviors and seek out coding flaws, back doors, and potentially malicious code.
  • Dynamic Analysis adopts the opposite approach of Static Analysis and is executed while a program is in operation.
    • A dynamic test will monitor system memory, functional behavior, response time, and overall performance of the system.
  • Dynamic Analysis involves the testing and evaluation of a program based on its execution.
    • Static and Dynamic Analysis, considered together, are sometimes referred to as glass-box testing.
    • Dynamic program analysis tools may require loading of special libraries or even recompilation of program code.
    • Dynamic Analysis is capable of exposing a subtle flaw or vulnerability too complicated for Static Analysis alone to reveal and can also be the more expedient method of testing.
    • A dynamic test will only find defects in the part of the code that is actually executed.
  • Dynamic Analysis adopts the opposite approach of Static Analysis and is executed while a program is in operation.
    • A dynamic test will monitor system memory, functional behavior, response time, and overall performance of the system.
  • See Scrum and Testing and Scrum Testing and Practices

Dynamic Systems Development Method (DSDM)

Dynamic Systems Development Method (DSDM) phases

  • Similar to scrum, Dynamic Systems Development Method (DSDM) has three major phases: initiating project activities, project life cycle activities, and closing project activities (i.e., similar to scrum’s pre-game, game, post-game).
  • The 3 phases of Dynamic Systems Development Method (DSDM) :
    • Initiating project activities
    • Project life cycle activities
      • The project life cycle has five stages :
        • feasibility study,
        • business study,
        • functional model iteration,
        • design and build iteration,
        • implementation.
    • Closing project activities
    • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Earned Value (EV)

Earned Value Analysis (EVA)

  • Earned Value Analysis is he process of measuring project performance against the performance defined in a baselined plan.
    • used in earned value management (EVM)
    • 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, earned value management for agile projects
  • EVM or earned value management (EVM) is a management technique used to evaluate project performance with respect to cost and schedule. [Agile Estimating and Planning. Mike Cohn.]
  • EVM or earned value management relies on other common financial metrics like Budget At Completion (BAC), Actual Cost (AC), Planned Value (PV), Earned Value (EV), Cost Variance (CV), Schedule Variance (SV), Cost Performance Index (CPI), and Schedule Performance Index (SPI). [Agile Estimating and Planning. Mike Cohn.]
    • Elements of Earned Value Management (EVM) :
      • BAC: Budget at completion
      • EV : Earned Value is value of work actually completed or earned (e.g., you have completed 50% of the project by week 5 of a 15 week $15,000 project = $7,500 EV).
      • CPI : Cost Performance Index (CPI)
        • CPI = EV / AC
        • AC is the actual cost the project has incurred to date.
        • < 1 is bad, = 1 is good, > 1 is good
      • CV : Cost Variance (CV)
        • CV = EV – AC
        • < 0 is bad, = 0 is good, > 0 is good
      • PV : Planned value
        • PV is the planned value of work at a given time in a project; you can calculate it by multiplying the BAC by the ratio of current week/scheduled weeks (e.g., 5 weeks into a 15 week $15,000 project = $5,000 PV).
      • SPI : Schedule Performance Index (SPI)
        • SPI = EV / PV
        • If SPI > 1, the project is ahead of schedule and if SPI < 1, the project is behind schedule.
        • < 1 is bad, = 1 is good, > 1 is good
      • SV : Schedule variance
        • SV = EV – PV
        • 0 is bad, = 0 is good , > 0 is good
  • [Agile Estimating and Planning. Mike Cohn.]

Earned Value Management (EVM) for Agile Projects

  • Earned Value Management is a tool used in traditional project management to measure the progress (in terms of realization of values) of the project
  • In Agile, EVM is the measure of cost performance of the Agile project though the estimate and actual costs (money spent) can be plotted as a S-curve graph to clearly show whether the project is under- or over-budget, it does not tell whether the progress of the project is ahead of or behind schedule
    • Value (story points and money) is calculated at the end of each iteration for work done
    • For the construction of the graph for EVM :
      • The baseline for comparison:
        • number of planned iterations in a release
        • planned story points in the release
        • planned budget for the release
      • Actual measurements:
        • total story points completed
        • number of iterations completed
        • actual Cost (actual spending) to date
        • any story points added / removed from the plan (as Agile project requirements are ever-changing)
      • Plotting the chart:
        • x-axis: iterations / date
        • y-axis: i) story points planned; ii) story points completed, iii) planned budget; iv) actual costs
        • discrepancies between i) and ii) / iii) and iv) reflect the performance of the release
      • Formulas for EVM
        • Schedule Performance Index (SPI) = Earned Value / Planned Value
        • Cost Performance Index (CPI) = Earned Value / Actual Cost
        • EVM does not indicate the quality of the project outcome, i.e. whether the project is successful or not

Efferent Coupling

  • It is a code quality metric.
  • Efferent Coupling is a coupling metric in software development.
    • It measures the number of data types a class knows about.
    • Efferent Coupling measures the number of data types a class knows about.
    • This includes inheritance, interface implementation, parameter types, variable types, and exceptions.

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.

Elapsed Time

  • The actual amount of time it will take to complete the User Story.

Emergence

  • The process of the coming into existence or prominence of new facts or new knowledge of a fact, or knowledge of a fact becoming visible unexpectedly.

Emergent Architecture definition

  • The Development Team should handle architectural and infrastructural concerns as a part of other Product Backlog Items or through independent architectural and infrastructural items during each Sprint.
  • See Scrum and the Emergent Architecture

Emotional intelligence

  • Having a high emotional intelligence means self-awareness, control over your own emotions, and being attentive to other team members’ emotions.
    • A high emotional intelligence allows team members to collaborate effectively. [Coaching Agile Teams. Lyssa Adkins.]
  • People with higher emotional intelligence (E.Q.) can relate to the feeling of people so that they deal with people issues more effectively
  • Emotional intelligence uses seven components :
    • Self-awareness,
    • Emotional resilience,
    • Motivation,
    • Interpersonal sensitivity,
    • Influence,
    • Intuitiveness,
    • Conscientiousness.
    • [Coaching Agile Teams. Lyssa Adkins.]

Empathy

  • Customer-programmer empathy and programmer-tester empathy help generate team trust on an agile project. [The Art of Agile Development. James Shore.]

Empiricism

  • Process control type in which only the past is accepted as certain and in which decisions are based on observation, experience and experimentation. Empiricism has three pillars: transparency, inspection and adaptation.

Empowered Teams

  • A team is “a small number of people with complementary skills who are committed to a common purpose, performance goals and approach for which they hold themselves mutually accountable” ~Jon Katzenbach and Douglas SmithAgile teams are, ideally, highly motivated by practising self-management and self-organization.
    • The organization gives the Agile team a high level of trust.
  • Empowered teams are :
    • self-organizing :
      • since the team has the best knowledge about the project and is in the best position to organize project works
    • self-directing :
      • the team can make their own decisions, not to be directed from the management
    • empowered team is more productive and efficient than teams with top-down decision making
    • mutual accountability and collective project ownership promote empowerment so that the team work as one whole

Empowerment

  • Create a high performing team in which members can perform as generalizing specialists carrying out cross-functional tasks.
    • Empower team members to make decisions and to lead in order to create a self-organizing team.
    • Understand motivators and demotivators of the team and individuals to ensure high team morale.

Energized work

  • (work only as many hours as you can be productive and only as many hours as you can sustain.)

Engineering standards

  • A shared set of development and technology standards that Developers apply to create releasable Increments of software.

Environment

  • A warm, welcoming environment that promotes effective communication, innovation, and motivated team members is an important aspect to consider when designing team space.
    • Guidelines for a better agile team space include: collocation of team members; reduction of nonessential noise/distractions; dedicated whiteboard and wall space for information radiators; space for the daily stand-up meeting and other meetings; pairing workstations; and other pleasantries like plants and comfortable furniture. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Epics

  • Epics are almost always delivered over a set of Sprints.
    • A team will learn more about an epic through development and customer feedback, and user stories will be added and removed to optimize the team’s time.

Epic Story

  • a large block of functionality (usually requires several iterations), epic stories will later be disaggregated into smaller User Stories for estimation and implementation

Escaped defects

  • Escaped defects are defects that are not discovered by the team but by the customer, escaped defects are a measure of the effectiveness of Testing and quality control measures
    • Agile performance (on quality) can also be measure by the number of escaped defects (defects found by customers)
      • defects should be found and fixed during coding and testing
      • defects found early are much less expensive to fix than defects found late
    • i.e. if the escaped defects increase, root cause analyses such as five WHYs or fishbone diagram should be carried out with a view to reduce 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.]
    • Escaped Defects are those defects reported by the Customer from production that have escaped all software quality processes are represented in this metric.
  • See Agile technical debt and escaped defects

Estimation

  • Definition:
    • Estimation is the process of assigning a quantifiable measure to the amount of workload needed to complete a project or task, in order to determine the duration, effort, or cost required to complete the project or task.
  • How it’s Used:
    • The Agile team must reach a consensus on an estimate for workload effort or duration needed to complete the task based on individual estimates provided by team members.
    • This can take the form of a game known as Planning poker.
  • Project Management Benefits:
    • Provides an indication of overall duration, effort, or cost of a software project.
    • Reduces uncertainty related to cost and duration.
    • Provides a guideline for estimating tasks or projects.

Expectancy Theory (VROOM)

  • an individual will decide to behave or act in a certain way because they are motivated to select a specific behavior over other behaviors due to what they expect the result of that selected behavior will be
    • for a person to be motivated, efforts/performance/outcome must be matched – will only work hard for achievable goals
  • key elements of Expectancy Theory
    • Expectancy
      • extra work will be rewarded
    • Instrumentality
      • good results will be rewarded
    • Valence
      • the individual’s expected reward

Exploratory testing

  • Exploratory Testing seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases by asking test subjects to try the software
  • Exploratory Testing and Usability testing both will provide valuable feedback early in the project to enhance value delivery and avoid failure later on

EVM (Earned Value Management)

  • EVM, earned value management for agile projects
  • EVM or earned value management (EVM) is a management technique used to evaluate project performance with respect to cost and schedule. [Agile Estimating and Planning. Mike Cohn.]
  • EVM or earned value management relies on other common financial metrics like Budget At Completion (BAC), Actual Cost (AC), Planned Value (PV), Earned Value (EV), Cost Variance (CV), Schedule Variance (SV), Cost Performance Index (CPI), and Schedule Performance Index (SPI). [Agile Estimating and Planning. Mike Cohn.]
    • Elements of Earned Value Management (EVM) :
      • BAC: Budget at completion
      • EV : Earned Value is value of work actually completed or earned (e.g., you have completed 50% of the project by week 5 of a 15 week $15,000 project = $7,500 EV).
      • CPI : Cost Performance Index (CPI)
        • CPI = EV / AC
        • AC is the actual cost the project has incurred to date.
        • < 1 is bad, = 1 is good, > 1 is good
      • CV : Cost Variance (CV)
        • CV = EV – AC
        • < 0 is bad, = 0 is good, > 0 is good
      • PV : Planned value
        • PV is the planned value of work at a given time in a project; you can calculate it by multiplying the BAC by the ratio of current week/scheduled weeks (e.g., 5 weeks into a 15 week $15,000 project = $5,000 PV).
      • SPI : Schedule Performance Index (SPI)
        • SPI = EV / PV
        • If SPI > 1, the project is ahead of schedule and if SPI < 1, the project is behind schedule.
        • < 1 is bad, = 1 is good, > 1 is good
      • SV : Schedule variance
        • SV = EV – PV
        • 0 is bad, = 0 is good , > 0 is good
  • [Agile Estimating and Planning. Mike Cohn.]

EVM (Earned Value Management) for Agile Projects

  • Earned Value Management is a tool used in traditional project management to measure the progress (in terms of realization of values) of the project
  • In Agile, EVM is the measure of cost performance of the Agile project though the estimate and actual costs (money spent) can be plotted as a S-curve graph to clearly show whether the project is under- or over-budget, it does not tell whether the progress of the project is ahead of or behind schedule
    • Value (story points and money) is calculated at the end of each iteration for work done
    • For the construction of the graph for EVM :
      • The baseline for comparison:
        • number of planned iterations in a release
        • planned story points in the release
        • planned budget for the release
      • Actual measurements:
        • total story points completed
        • number of iterations completed
        • actual Cost (actual spending) to date
        • any story points added / removed from the plan (as Agile project requirements are ever-changing)
      • Plotting the chart:
        • x-axis: iterations / date
        • y-axis: i) story points planned; ii) story points completed, iii) planned budget; iv) actual costs
        • discrepancies between i) and ii) / iii) and iv) reflect the performance of the release
      • Formulas for EVM
        • Schedule Performance Index (SPI) = Earned Value / Planned Value
        • Cost Performance Index (CPI) = Earned Value / Actual Cost
        • EVM does not indicate the quality of the project outcome, i.e. whether the project is successful or not

Exploratory Testing

  • Exploratory Testing is all about discovery, investigation, and learning.
    • It emphasizes personal freedom and responsibility of the individual tester.
    • It is defined as a type of testing where Test cases are not created in advance but testers check system on the fly.
    • They may note down ideas about what to test before test execution.
    • The focus of exploratory testing is more on testing as a “thinking” activity. Exploratory test cannot be automated.
  • Attributes of Exploratory Testing :
    • it involves minimum planning and maximum test execution
    • it is unscripted testing

Extra motion

  • If excessive or unnecessary emails and document get forwarded multiple times sometimes with large attachments due to multiple distribution groups, it constitutes waste of type motion.
  • Do not confuse with “Extra Transportation” which refers to unnecessary motion or movement of raw materials or goods such, as work-in-process (WIP) being transported from one operation to another.

Extreme Programming (XP)

  • Extreme Programming or eXtreme Programming (XP) is an agile software development framework with an extreme focus on programming and taking engineering practice to an extreme in order to create and release high quality code.
  • eXtreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.
    • As a type of agile software development, it advocates frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
  • Other elements of eXtreme Programming (XP) include: programming in pairs or doing extensive code review, unit testing of all code, not programming features until they are actually needed, a flat management structure, code simplicity and clarity, expecting changes in the customer’s requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.
    • The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to “extreme” levels.
    • As an example, code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously (i.e. the practice of pair programming).

Extreme Programming practices

  • eXtreme Programming (XP) takes the engineering practices to an extreme, in order to create and release high quality code.
  • Agile software development practices popularized by eXtreme Programming (XP) :
  • Extreme programming has been described as having 12 practices, grouped into four areas:
    • Fine-scale feedback
      • Pair programming
      • Planning game
      • Test-driven development
      • Whole team
    • Continuous process
      • Continuous integration
      • Refactoring or design improvement
      • Small releases
    • Shared understanding
      • Coding standards
      • Collective code ownership
      • Simple design
      • System metaphor
    • Programmer welfare
      • Sustainable pace

Extreme Programming (XP) values

Face-to-face communication

  • An open, face-to-face communication culture is the best suited culture for an agile team. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
  • Face-to-face communication enhances team collaboration. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Facilitated Workshops

  • Facilitated Workshops encourage collaborative working and enable high quality team-based decisions to be made in a shortened timeframe.
    • People brought together as a group communicate more effectively and generate more creative solutions.
    • A well-run Facilitated Workshop also delivers an outcome with a high degree of buy-in and ownership from those people who have taken part.
  • Ideally, workshops are independently facilitated by someone external to the project.
    • At the very least, the Workshop Facilitator should be independent of the workshop result, to ensure that all ideas and contributions are given equal weight.
    • A trained facilitator creates an environment that allows full participation.
  • Effective workshops follow a well-defined and carefully thought-out process.
    • This process should include defining the objective, identifying appropriate participants, creating an agenda, managing the logistics and distributing any pre-reading to participants.
  • Facilitated Workshops are particularly valuable when applied to activities such as requirements identification and refinement, prioritisation, Release Planning or Sprint Planning, risk analysis, Problem Solving, product Reviews and Retrospectives.

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.]
  • Facilitation methods :
    • Goals
      • Keep people focused with clear goals
    • Rules
      • Establish basic ground rules
    • Timing
      • Duration established ahead
    • Assisting
      • Facilitation so the meeting is productive & everyone contributes

Fail Fast

  • This is a strategy of trying something, getting feedback quickly and adapting.
    • This principle works well in high levels of uncertainty as it allows teams to determine right away whether or not they have made a good decision or if they need to kill it fast.

Feature

  • a capabilities / group of functionalities that is of value to the end user
  • 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.

Feature branching

Feature Creep

  • Definition:
    • Feature creep is the tendency to add additional requirements or features to a project after development is already underway.
      • Feature creep can occur on either a project or sprint level.
    • Also known as: Requirements creep, scope creep
  • How it’s Used:
    • Changes and additional requirements are to be expected in a project.
    • Any changes requested after the start of a project or sprint need to be added to the backlog and prioritized based on value.
    • This ensures that feature creep will not adversely impact the project timeline or cost.
  • Project Management Concerns:
    • Risks project schedule, quality, and cost.
    • Reduces productivity.
    • Prevents teams from meeting iteration goals.
    • Decreases value of product or deliverable.

Feature Driven Development (FDD)

  • Feature Driven Development (FDD) is an agile method popularized by Jeff De Luca and others that values some upfront architecture and works well for larger projects.
  • Feature Driven Development (FDD) uses a prescriptive model where the software development process is planned, managed, and tracked from the perspective of individual software features.
  • The five step Feature Driven Development (FDD) process is :
    • Develop overall model;
    • Create the features list;
    • Plan by feature;
    • Design by feature;
    • Build by feature.
    • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Feature Toogle

  • Software development practice that allows dynamically turning functionality on and off.
    • Feature toggle doesn’t impact the overall accessibility of the system by users.
  • See Technical Practices

Fibonacci Sequence

  • Definition:
    • Originally derived in the 12th century by Leonardo Pisano, the Fibonacci Sequence is a mathematical sequence in which each subsequent number is determined by the sum of the two previous numbers, that is: 1, 2, 3, 5, 8, 13, 21…
    • Each interval becomes larger as the numbers increase:
  • How it’s Used:
    • Teams often use the Fibonacci Sequence when playing the game of Planning poker to estimate workload.
    • The numbers are relative and have no unit of measurement assigned.
  • Project Management Benefits:
    • Establishes a scale or standard of comparison for estimating.
    • Increases accuracy of estimates.

Final Wireframes/Mock-Ups

Fishbone Diagram

  • another tool for carrying out cause and effect analysis to help discover the root cause of a problem or the bottle-necks of processes
    • aka cause and effect diagrams/Ishikawa diagrams
    • to use Fishbone diagram technique:
      • write down the problem/issue as the “fish head” and draw a horizontal line as the “spine” of the fish
      • think of major factors (at least four or above) involved in the problem/issue and draw line spinning off from the spine
      • representing each factor
      • identify possible causes and draw line spinning off the major factors (your diagram will look like a fishbone now)
      • analyze the fishbone diagram to single out the most possible causes to carry out further investigation

Fixed Price Workpackages

  • This approach allows customer to reprioritize the remaining work based on evolving costs, and it gives the ability to update their costs as new details emerge, removing the need for excessive contingency funds

Flow

  • Delivering a constant slow delivery of value to the end customer instead of batching together large releases and dropping them all at once.
  • Flow is the movement of potential value through a system.
    • As most workflows exist to optimize value, the strategy of Kanban is to optimize value by optimizing flow.
  • The four basic metrics of flow that Scrum Teams using Kanban need to track are as follows:
    • Work in Progress (WIP)
    • Cycle Time
    • Work Item Age
    • Throughput
  • Work in Progress (WIP):
    • The number of work items started but not finished.
    • The team can use the WIP metric to provide transparency about their progress towards reducing their WIP and improving their flow.
    • Note that there is a difference between the WIP metric and the policies a Scrum Team uses to limit WIP.
  • Cycle Time :
    • The amount of elapsed time between when a work item starts and when a work item finishes.
  • Work Item Age:
    • The amount of time between when a work item started and the current time.
      • This applies only to items that are still in progress.
  • Throughput:
    • The number of work items finished per unit of time.

Focus

  • With the Scrum framework, when you hear the value focus, you should be thinking about two things :
    • Identification of correct work :
      • What tasks are necessary to deliver the goals of my Sprint?
      • What are essential to developing the best software products and services for my clients so that they will be pleased with my work?
    • Prioritization :
      • What tasks should I be working on next?
      • Each moment in time, there is one critical question that the entire Scrum Team, including Scrum Master and Product Owner, must be answering.
      • This question is:
        • “What are the most important things we should be doing at the moment to fulfill reasons of why an employer hired us in the first place?”
      • Scrum framework has several built-in events (rituals) to ensure the reasonable prioritization of Product Backlog Items and tasks.
        • According to the Scrum process, the prioritization of Product Backlog Items and their associated tasks should have a continuous priority.
        • So we make sure that the Scrum Team works on the right things in the correct order.
        • Some of the built-in scrum ceremonies (Scrum Events) to prioritize our work and adjust our focus are:
          • Product Backlog Refinement:
          • Sprint Planning :
            • These meetings help us see the dependencies and correct order of work to deliver our Product backlog Items.
          • Daily Scrum :
            • Daily Scrum (Daily Stand-Up) supports us to set the tone of an upcoming workday.
            • We must direct our focus on where it’s most required.
          • Sprint Review :
            • Sprint Review indirectly shows us where the emphasis of the Scrum Team must be channeling to have more successful reviews in the future.
          • Sprint Retrospective :
            • Sprint Retrospective support the scrum team to prioritize what aspects of their engineering process must be first improved.
      • Having read all these, it must be evident how essential prioritization and focus for the Scrum framework are.

Focus and Crystal methodologies

  • Executives and leaders must set priorities and make it clear what developers should be spending their time on.
    • Then the Developers must be given time, without interruptions, to work on those priorities.
    • Working on one project at a time is ideal; two maximum.
    • Teams should set up two hours of each working day (say 10am to 12 noon) where no interruptions are allowed including meetings, phone calls, and demos.
  • Agile and Crystal methodologies

Forecast (of functionality)

Frequent Validation and Verification

  • early and frequent Testing both within and outside the Developers to reduce the cost of quality (change or failure)
  • validation :
    • usually external, validation is the assurance that a product, service, or system meets the needs of the customer
  • verification :
    • usually internal of team, verification is the evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition
  • Agile measure to ensure frequent validation and verification :
    • testers are included in the Developers from the beginning taking part in user requirements collection
    • Unit Testing (UT) is created for continuous feedback for quality improvement and assurance
    • automated testing tools are used allowing quick and robust testing
    • examples :
      • peer reviews, periodical code-reviews, refactoring, unit tests, automatic and manual testing
      • feedback for various stages : team (daily) -> product owner (during sprint) -> stakeholders (each sprint) -> customers (each release)

FSM (Functional Size Measurement)

  • Function points are used to compute a functional size measurement (FSM) of software.

Fully Dressed Use Cases

  • Building on the Initial Use Cases, the Fully Dressed Use Cases include full definition of all alternate paths, exceptions and other supplementary information.

Functional Size Measurement (FSM)

  • Function points are used to compute a functional size measurement (FSM) of software.

Functional Test Scripts

  • Functional test scripts are generally written one for each use case to test the functional performance of the resulting solution.

Functional Testing

Functionality Flow Principle

  • Sunny Day, Rainy Day
  • Happy Path, Sad Path
  • Happy day (or sunny day) scenario and golden path are synonyms for happy path.
  • See Scrum and Coding Principles

Functional Spike

Function points (FP)

  • The Function point is a “unit of measurement” to express the amount of business functionality an information system (as a product) provides to a user.
  • See Metrics

Functional Size Measurement (FSM)

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.

General Purpose Language (GPL)

  • A general-purpose language (GPL) is a computer language which is broadly applicable across domains.
    • This is in contrast to a domain-specific language (DSL) is a computer language specialized to a particular application domain.

Glass-Box Testing

Governance

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

GPL (General Purpose Language)

  • A general-purpose language (GPL) is a computer language which is broadly applicable across domains.
    • This is in contrast to a domain-specific language (DSL) is a computer language specialized to a particular application domain.

Graduated Fixed Price Contract

  • under this contract if the seller delivers on time they get paid for the contract under standard rate, early delivery + rate, late delivery – rate

Graphic Elements

  • Graphic elements are the .JPG and .GIF files that are implemented in the web pages to produce the desired look and feel of the website.

Happy-pass Testing

  • Happy Pass testing (or Sunny Day testing) is a type of software testing that uses known input and produces an expected output.
    • Also referred to as golden-path or sunny-day testing, the happy-path approach is tightly scripted.
    • The happy path does not duplicate real-world conditions and verifies only that the required functionality is in place and functions correctly.
    • If valid alternatives exist, the happy path is then identified as the default scenario or the most likely positive alternative featuring no exceptional or error conditions.
  • In the context of software or information modeling, a happy path (sometimes called happy flow) is a default scenario featuring no exceptional or error conditions.
    • For example, the happy path for a function validating credit card numbers would be where none of the validation rules raise an error, thus letting execution continue successfully to the end, generating a positive response.
  • Process steps for a happy path are also used in the context of a use case.
    • In contrast to the happy path, process steps for alternate paths and exception paths may also be documented.
  • Happy path test is a well-defined test case using known input, which executes without exception and produces an expected output.
    • Happy path testing can show that a system meets its functional requirements but it doesn’t guarantee a graceful handling of error conditions or aid in finding hidden bugs.
  • In use case analysis, there is only one happy path, but there may be any number of additional alternate path scenarios which are all valid optional outcomes.
    • If valid alternatives exist, the happy path is then identified as the default or most likely positive alternative.
    • The analysis may also show one or more exception paths.
    • An exception path is taken as the result of a fault condition.
    • Use cases and the resulting interactions are commonly modeled in graphical languages such as the Unified Modeling Language or SysML.
  • See Scrum and Coding Principles

Herzberg’s Hygiene Theory

  • satisfaction (motivators) :
    • such as recognition, achievement or personal growth
    • these are key factors to make team members motivated
    • salary is not an effective motivator
  • dissatisfaction (demotivators) :
    • such as bad working conditions, unfairness, etc.
  • hygiene factors are factors that must be present to avoid dissatisfaction but do not provide satisfaction, also called KITA factors
    • e.g. Company policies, supervision, relationship with supervisor and peers, work conditions, salary, status, job security

High Performing Team

  • maximize performance by :
    • clear and realistic goals
    • building trust
    • open and honest communication
      • even in case of disputes or conflicts
    • taking ownership, empowered, self-organizing
    • coaching and mentoring
    • choose teammates with complementary skills to perform all tasks
    • sense of belonging (identity)
    • limiting each team to have 12 members or below, break down the team if needed
    • make decisions through consensus (participatory decision model)
    • full-time, dedicated members

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.]

Ideal days

  • Instead of using story points, agile teams may estimate the relative sizes of User Stories using ideal days.
    • Ideal days represents the amount of days – uninterrupted by meetings, personal life, non-working days, or any other delays, obstacles or distractions – that it would take a single person to build, test, and release the User Story, relative to other User Stories in the backlog. [Agile Estimating and Planning. Mike Cohn.]
  • The agile estimation technique of ideal days ignore, discount, or simplify delays, obstacles, non-working days, and the possibility that multiple developers may work on the user story.

Ideal time

  • A unit used in estimation of Agile tasks:
    • ideal time is a block of uninterrupted period to focus solely on the task without any distractions e.g. email, phone call, toilet break, etc..
    • Though ideal time is NOT realistic in actual world, it does give an accurate unit to begin working with (e.g. by multiplication of a factor of 2 to 3 to give a reasonable estimate)
  • Time spent exclusively on the task, with no interruptions and in a good work disposition.
    • The time we estimate it will take to complete a story uninterrupted (consider this an estimate of size).

Idle Time

  • Unproductive time on the part of employees or machines as a result of factors beyond their control.
    • Idle time is the time associated with waiting, or when a piece of machinery is not being used but could be.
    • Idle time could also be associated with computing, and in that case refers to processing time.

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.
  • I Know It When I See It (IKIWISI), is most of the time the most valuable tool for accepting the new functionality in its environment.

Impediment

  • Definition:
    • An impediment is any obstacle that prevents an individual or team from completing a task or project.
    • Unscheduled meetings, technical issues, lack of knowledge or expertise, a distracting workplace, and office conflict are all examples of impediments.
  • How it’s Used:
    • The team may want to create a list of impediments called an Impediment Backlog and prominently display this list in the area where the team meets for Daily Scrums.
    • Impediments should be listed by how seriously they are hindering team productivity.
      • If the impediments are company-wide, it is the Scrum Masters responsibility to remove them.
      • If they are occurring at a team level, it is the team’s responsibility to resolve or remove them.
  • Project Management Concerns:
    • Results in reduced team productivity.
    • Negatively impacts project timeline and cost.
    • Needs to be addressed as soon as possible.

Inadvertent Debt

Incremental Debt

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.]
  • With the incremental delivery the team regularly deploys working Increments of the product.
    • In software development the working software is usually deployed to a test environment & if it makes sense to business the team could deliver functionality to production.
    • When delivered to a test environment incremental delivery reduces the amount of rework by finding issues early.

Incremental Development

  • Develop the product incrementally to reduce risk and deliver value fast.
    • Inspections, Testings and Reviews with stakeholders are carried out periodically to obtain feedback and make corrections as necessary.
    • Retrospectives allow overall improvements to be made to the project process.

Information radiator

  • A communication tool to physically displays key information about the current project status to the Agile team/stakeholders in the work area in the most visible and efficient manner, e.g. Kanban Board
  • Information radiators are highly visible charts and figures displaying project progress and status, e.g. Kanban Board, Burn-Down Chart.
    • These shows the real progress and performance of the project and team which enhances transparency and trust among team members and other stakeholders.
  • An information radiator is a visual representation of project status data. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • An information radiator displays project status-related information, such as user story development status, burndown charts, and task boards. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • A visual representation or chart that shows project status regarding a tracked project-related metric.
    • An information radiator should be posted in a highly visible area that is easily accessible by the team and stakeholders. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • Information radiators do not increase the efficiency of software developers.
      • The use of information radiators on an agile project offer several advantages.
      • They reduce lengthy communication, allow for all team members and stakeholders to review project status throughout a project, and reduce the need of other more time-consuming communication methods, like e-mails or memorandums.
      • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
  • All successful projects, regardless of management philosophy, require project planning.
    • The use of information radiators on an agile project offer several advantages.
    • They reduce lengthy communication, allow for all team members and stakeholders to review project status throughout a project, and reduce the need of other more time-consuming communication methods, like e-mails or memorandums. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
  • Information radiators improve team communication by reducing the amount of time spent explaining project status. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • Typical information radiators on an agile project include: project Burn-Down Charts, Tasks boards, Burn-Up Charts, and defect charts. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • Information radiators should be updated whenever the posted data has changed to keep all team members and stakeholders up to date. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • Typical information radiators :

Initial Use Cases

  • Initial use cases expand upon the candidate use case information by including definition of stakeholders, pre-conditions, post-conditions and the main success scenario.
    • Initial use cases should also include a list of expected alternate paths and exceptions without fully dressing them out.

Initial User Interface Prototypes

  • Defining the solution will also generally require some design work into the usability of the system by preparing one or more flavours of user interface prototypes such as wireframes or page mock-ups.

Innovation games

  • games are used to engage the team members and customer, e.g. 20/20 Vision, the Apprentice, Buy a Feature, Product Box, Prune the Product Tree (reference: Innovation Games: Creating Breakthrough Products Through Collaborative Play by Luke Hohmann).

Instability Index

Integration Testing

  • Individual units are combined and tested as a group in order to expose faults in the interaction of units.
  • Integration Testing, also known as integration and testing (I&T), is a type of testing in which program units are combined and tested as groups in multiple ways. Integration test can be automated.
  • Integration Testing is performed on the modules that are Unit Test first and then Integration Testing defines whether the combination of the modules give the desired output or not.

Integration, Testing and Experiments

  • Continuous Integration (CI) (as a core practice in eXtreme Programming
    • [usually for IT projects] to continuously integrate changes (usually in small trunks) to the codebase by merging the new codes as soon as practicable (i.e. once ready)
    • to avoid code conflicts and minimize risks of incompabitility
    • on every integration, the codebase needs to be tested (usually by Unit Testing (UT) with automated testing tools / Regression Testing tools)
    • typical setup for continuous integration :
      • A source code repository
      • A check-out and check-in process
      • An automated build process (compiles codes, runs tests and deploys)
    • if errors are found, fixing the broken build is of top priority
  • Continuous Improvement
    • the Deming’s PDCA Cycle (plan – do – check -act)
    • make use of process improvement and self-assessment for improved product
      • e.g. code refactoring and pair programming
  • Testing (Exploratory and Usability)
    • Exploratory Testing
      • seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases by asking test subjects to try the software
    • Usability testing
      • a special type of exploratory testing with emphasis on the usability of the software interface (whether the test subject will be able to perform core tasks on the interface without instructions and help)
      • help to provide insights on the design of the software :
        • Users’ expectations / habits
        • Users’ ability to understand / comprehend the design of the interface
        • Users’ value of the functions of the software
    • both will provide valuable feedback early in the project to enhance value delivery and avoid failure later on
  • Learning Cycle
    • Agile software development is about learning
      • from little known about the end product in the beginning to (hopefully) delivering the maximal value in the end
    • understanding of the requirements as well as the technology to make the product feasible increase incrementally during the project
    • each Retrospective or Review is an opportunity to learn
    • it is recommended to keep learning cycles short so that new knowledge gained can be fed into the project as soon as possible

Intraspectives

  • intra = inside / within, (per)spective = a particular way of viewing things / inspection :
    • intraspective = inspecting within / seeing inwardly
  • intraspectives in Agile project management is an ad hoc discussion / meeting by the Agile team to review on the team practices or teamwork during the Sprint, often called for when something went wrong

Iteration backlog

  • responsible by the team, the iteration backlog contains tasks for the iteration in which tasks are allocated through self-organization (team members select the tasks they are most interested in)

Interface Segregation Principle

  • I – Interface Segregation Principle.
    • This Principle States that once an interface is becoming too large/fat, we absolutely need to split it into small interfaces that are more specific.
      • Interface Segregation principle: A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use

Innovation games / Agile games

  • The phrase innovation game refers to a form of primary market research developed by Luke Hohmann where customers play a set of directed games as a means of generating feedback about a product or service.
    • The research is primary because the data collected is gathered directly from customers or prospects and is intended to answer a specific research question.
    • Secondary research is data collected previously by others, usually through primary research, that may or may not address a specific research question.
    • “Customers” who play innovation games are commonly direct recipients or consumers of a specific product or service.
    • In some cases, though, game players may be any person or system who is or would be affected by a product or service.
  • See Agile games

Inspect and Adapt

Inspect and Adapt practice

  • Step 1 : Inspect
    • We do our best to grasp the current status of the project with our current level of knowhow and understanding about it.
  • Step 2 : Adapt
    • We define a direction and vision about the next steps of our project and then strategize and execute our vision.
  • Step 3 : Learn
    • We carefully observe, learn, and teach each other while we do so.
    • We continuously log what works and what doesn’t work while we do our work.
  • Step 4 : Restart
    • Start over from Step 1 again.
  • Note that those four steps described above are analog, but not limited to the following Scrum rituals (Scrum Events).
  • See Inspect and Adapt and The three pillars, Transparency, Inspection and Adaptation

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.]

Internal Rate of Return (IRR)

  • Internal Rate of Return (IRR) : this is somewhat like the interest rate of the investment;
    • the higher the positive IRR, the more profitable the project

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.

INVEST (for User Stories)

  • INVEST : Independent, negotiable, valuable, estimable, small, and testable
    • The acronym INVEST (independent, negotiable, valuable, estimable, small, and testable) helps the agile practitioner remember the characteristics of a good User Story.
    • I – Independent stories can be developed in any order and avoid dependencies which can make development more complex. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
    • N – Negotiable User Stories mean that both the customer and Developers should feel free to analyze and adapt a user story to meet customer needs. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
    • V – A valuable User Story describes how the product feature will provide value to the customer. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
    • E – Estimable User Stories are ones that Developers can readily estimate the effort or duration required for developing them. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
    • S- Small User Stories are ones that take about two to five days of work to implement. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
    • T – Testable User Stories are ones that can be verified according to acceptance criteria to ensure value. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

IRR

  • Internal Rate of Return (IRR) : this is somewhat like the interest rate of the investment;
    • the higher the positive IRR, the more profitable the project
  • The internal rate of return (IRR) is a financial metric used to measure and compare the profitability of investments.
    • The IRR is the « rate » that makes the net present value of all cash flows from a particular investment equal to zero.
    • Unlike NPV which is a dollar amount (i.e., a magnitude) value, the IRR is a rate (i.e., a percentage).
    • Often times, the IRR is compared against a threshold rate value to determine if the investment is a suitable risk worth implementing.
    • For example, you might calculate an IRR to be 13% for an investment while a comparative market rate is 2%.
    • The IRR being larger than the comparative market rate, would indicate the investment is worth pursuing.
    • [Agile Estimating and Planning. Mike Cohn.]
  • Select project with biggest IRR.

Iteration

  • A cornerstone of Agile development is ‘incremental delivery.’
  • An iteration is a time-boxed amount of work that the team sets out to complete.
    • Ideally, all of the work within this period of time will be 100% completed and the resulting work will be ready to ship at the end of the period.
    • Most iterations run about one week to one month in length.
    • The iteration most often begins with planning and ends with a retrospective.
  • Iteration is a short, fixed time period (typically between 1 and 4 weeks) during which the team produce a potentially deployable release of software for evaluation.
  • 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.]

Iteration Backlog

  • An agile team creates the iteration backlog during iteration planning [The Art of Agile Development. James Shore.]

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)

Iteration planning

  • 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.”

Iteration Review

  • Iteration review is a step where stakeholders look at the progress by looking at working software.
    • Because the Product Owner is responsible for ROI and has the most knowledge on what the complete objectives are for a product, the Product Owner should lead the Sprint Review. [Agile Project Management with Scrum. Ken Schwaber.]

Iterative Development

  • Definition:
    • Iterative development is the process of breaking down projects into more manageable components known as iterations.
    • Iterations are essential in Agile methodologies for producing a potentially shippable deliverable or product.
  • Also known as: Incremental development
  • How it’s Used:
    • In iterative development, Agile teams design, develop, and test code in repeated cycles.
    • After each iteration is complete, the team gathers user feedback and then uses those insights to build the next iteration of the product. Iterative development allows teams to assess and adapt their processes, which leads to continuous improvement.
  • Project Management Benefits:
    • Improves customer satisfaction.
    • Adds value to product.
    • Enables faster delivery of working software or product.
    • Leads to continuous improvement.

Jidoka

  • Jidoka is a Japanese term used for autonomation means “intelligent automation” or “humanized automation.”
    • In practice, it means that an automated process is sufficiently “aware” of itself so that it will detect when the desired quality is produced, detect process malfunctions, detect product defects, stop itself and alert the operator.
    • A future goal of autonomation is self-correction.

Kaizen

  • a Japanese management philosophy in which the project and processes are being checked and improved continuous for better value delivery

Kanban

  • Kanban is a popular framework that is used to implement agile software development.
    • It refers to real-time communication of capacity and full transparency of work.
    • Most times, work items are represented visually on a Kanban board which allows members to see the progress of any piece of work at any time.
  • Kanban is a strategy for optimizing the flow of value through a process that uses a visual, workin-progress limited pull system.
  • There may be various ways to define value, including consideration of the needs of the customer, the end-user, the organization, and the environment, for example.
  • Kanban comprises the following three practices working in tandem:
    • Defining and visualizing a workflow
    • Actively managing items in a workflow
    • Improving a workflow
  • In their implementation, these Kanban practices are collectively called a Kanban system.
  • Those who participate in the value delivery of a Kanban system are called Kanban system members

Kanban Board

  • Kanban, Japanese for billboard or signboard, is a scheduling system for just-in-time (JIT) production developed by Toyota in the 1940s and 1950s
  • a Tasks board showing the progress of tasks through the project processes, can be tailor-made to suit individual projects
    • a WIP limit (work-in-progress) would be enforced to ensure efficiency
    • WIP means “Work In Progress” – a work that has been started but not yet reach “done”
    • WIP can also be considered to be the size of the job queue
  • More at Tasks board and Kanban Board

Kanban Metrics

  • The application of Kanban requires the collection and analysis of a minimum set of flow measures (or metrics).
  • They are a reflection of the Kanban system’s current health and performance and will help inform decisions about how value gets delivered.
  • The four basic metrics of flow that Scrum Teams using Kanban need to track are as follows :
    • Work in Progress (WIP)
    • Cycle Time
    • Work Item Age
    • Throughput

Kanban rules

  • Never Pass Defective Products
  • Take Only What’s Needed
  • Produce the Exact Quantity Required
  • Level the Production
  • Fine-tune the Production or Process Optimization
  • Stabilize and Rationalize the Process

Kanban ten steps

  • Visualizing your workflow
  • Limit Work in Progress (WIP)
  • Set Up Quality Assurance Policies and Make Them Explicit
  • Adjust Cadences
  • Measure Flow
  • Prioritize
  • Identify Classes of Service
  • Manage Flow
  • Establish Service Level Agreements (SLA)
  • Focus on Continuous Improvement

Kanban with Scrum Theory

  • Kanban with Scrum is Flow and Empiricism
    • Central to the definition of Kanban is the concept of flow.
      • Flow is the movement of value throughout the product development system.
      • Kanban optimizes flow by improving the overall efficiency, effectiveness, and predictability of a process.
      • Optimizing flow in a Scrum context requires defining what flow means in Scrum.
    • Scrum is founded on empirical process control theory, or empiricism.
      • Key to empirical process control is the frequency of the Transparency, Inspection and Adaptation cycle – which we can also describe as the Cycle Time through the feedback loop.
      • When Kanban practices are applied to Scrum, they provide a focus on improving the flow through the feedback loop; optimizing transparency and the frequency of inspection and adaptation for both the product and the process.
  • See Scrum and Kanban and Kanban Board

KANO analysis

  • priorities mapped in 4 categories :
    • EXITERS
      • features deliver unexpected high-value benefits to the customer
    • SATISFIERS
      • features bring expected value to the customer
    • DISSATISFIERS
      • Causes for the customer to dislike the product
    • INDIFFERENT
      • features have no impact

KISS Principle

  • The KISS principle states that most systems work best if they are kept simple rather than made complicated.
    • It is explained as “Keep it simple, silly”, “keep it short and simple”, “keep it simple and straightforward”, “keep it small and simple” and “keep it stupid simple”.
    • In addition, Simplicity should be a key goal in design.
    • KISS = Keep it simple stupid
    • KISS = Keep it simple, silly
    • KISS = Keep it small and simple
  • See Scrum and Coding Principles

Knowledge sharing

  • knowledge sharing / transfer is a key component of Agile project management
    • knowledge should be shared across the team, customer, community and organization

Last Responsible Moment

  • A strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision, the Last Responsible Moment
  • There may not actually be such a thing as a perfect decision, but there certainly is an optimal time to make it.
    • There is a cost of deciding and a cost of deferring and the last responsible moment sits perfectly at the intersection.
    • It will be hard to always perfectly time your decisions, and only you will know where that point is, but the key is to understand that there is an optimal decision making point.
  • Options Thinking lead us to invest time and money in delaying decisions to a time where we know the most about it; the extreme application of the Decide as late as possible principle is the concept of Last Responsible Moment, the optimal point of the trade-off between the available time for a decision and the need to complete a story or a task.
  • The last responsible moment is the instant in which the cost of the delay of a decision surpasses the benefit of delay; or the moment when failing to take a decision eliminates an important alternative.
    • For example, failing to provide a public HTTP API may make you lose an important customer, forcing you to publish an unfinished work.
  • See Scrum and Coding Principles and Last Responsible Moment

Lead time

Leading

  • As a team leader or agile project manager, you must facilitate communication between the development team and customer to ensure that requirements are understood and implemented correctly.
    • One of the four Agile Manifesto values underscores customer collaboration.
    • The team leader must facilitate this collaboration to deliver value.
    • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Lean

  • A primary goal of Lean is to optimize the whole with speed and sustainability.
    • The main principle of lean is to reduce any activities that do not provide value.
    • This can be summarized as “fast-flexible-flow,” which is the fundamental phrase used in Womack & Jones.
    • The agile process is a lean method for software development lifecycle.
  • 7 principles of Lean :
    • Eliminate waste
    • Amplify learning
    • Decide as late as possible
    • Deliver as fast as possible
    • Empower the team
    • Build integrity in
    • See the whole

Lean-Agile Leadership

  • The Lean-Agile Leadership competency describes how Lean-Agile Leaders drive and sustain organizational change and operational excellence by empowering individuals and teams to reach their highest potential.
  • Lean-Agile Leadership (3 dimensions) :
    • Mindset and Principles
    • Leading by Example
    • Leading Change
  • © Scaled Agile, Inc.

Lean Budget Guardrails

  • Guide investments by horizons
  • Use capacity allocation to optimize value and solution integrity
  • Approve significant initiatives
  • Insure of Continuous Business Owner engagement
  • See Lean Budget Guardrails

Lean manufacturing, lean-agile software development

Lean Software Development

  • In Lean Software Development (LSD), there are two forms of integrity :
    • conceptual integrity
      • Conceptual integrity is determined by the developers and is generally high if the product integrates well and functions as specified.
    • perceived integrity.
      • Perceived integrity is judged by the customer and is high if the customer is happy with the product, first and foremost, and secondly if the product meets requirements.
    • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
  • 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.]

Lean Software Development (LSD) practice

  • Definition:
    • Lean Software Development is an example of lightweight Agile methodology applied to project development.
      • Lean Software Development combines the Lean manufacturing approach pioneered by Toyota in the 1950s (also known as just-in-time production) and Lean IT principles, and applies them to software.
      • LSD places a strong emphasis on people and effective communication.
  • LSD is defined by seven principles:
    • Eliminate waste
    • Create knowledge
    • Build quality in
    • Defer commitment
    • Optimize the whole
    • Deliver fast
    • Respect people
  • How it’s Used:
    • The key goal of Lean Software Development is to reduce or eliminate waste, and therefore, focuses on streamlining products to include only the most valuable features and delivering them in increments.
    • Prioritization of backlog, short feedback loops, frequent unit testing, and team efficiency are all components of Lean Software Development.
    • LSD employs the Kanban approach of pulling work from the backlog, and improving workflow speed and efficiency.
  • Project Management Benefits:
    • Reduces overall project costs.
    • Increases workflow efficiency and speed.
    • Enables faster delivery of working software.
    • Increases motivation of team due to decision-making empowerment.

Lean Software Development principles

  • The 7 principles of Lean Software Development are :
    • Eliminate waste;
    • Amplify learning;
    • Decide as late as possible;
    • Deliver as fast as possible;
    • Empower the team;
    • Build integrity in;
    • See the whole.
    • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Learning Cycle

  • A learning cycle is a concept of how people learn from experience.
  • Agile software development is about learning
    • from little known about the end product in the beginning to (hopefully) delivering the maximal value in the end
    • understanding of the requirements as well as the technology to make the product feasible increase incrementally during the project
    • each Retrospective or Review is an opportunity to learn
    • it is recommended to keep learning cycles short so that new knowledge gained can be fed into the project as soon as possible

Least Privilege Principle

  • The principle of least privilege (PoLP; also known as the principle of least authority) is an important concept in computer security, promoting minimal user profile privileges on computers, based on users’ job necessities.
    • It can also be applied to processes on the computer; each system component or process should have the least authority necessary to perform its duties.
    • This helps reduce the “attack surface” of the computer by eliminating unnecessary privileges that can result in network exploits and computer compromises.
    • It can be applied to processes on the computer
    • It is also known as the principle of least authority
    • Promoting minimal user profile privileges on computers, based on users’ job necessities
    • Each system component or process should have the least authority necessary to perform its duties.
  • See Scrum and Coding Principles

Lines of Code (LOC)

  • It isn’t a code quality metric.
  • Lines of Code (LOC) is the number of lines in the text of the program’s source code.
  • Lines of Code (LOC) purpose
    • Lines of Code (LOC) is Code Metric which checks the Code Health.
      • Lines of Code (LOC) measures reward low level languages because more lines of code are needed to deliver a similar amount of functionality to a higher level language, C. Jones offers a method of correcting this in his work.
      • Lines of Code (LOC) measures are not useful during early project phases where estimating the number of lines of code that will be delivered is challenging.
      • However, Function points can be derived from requirements and therefore are useful in methods such as estimation by proxy.

Liskov Substitution Principle

  • L – Liskov Substitution Principle – This Principle confirms that objects should be replaceable by instances of their subtypes without affecting the functioning of your system from a client’s point of view.
    • Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
    • See Scrum and Coding Principles

Little’s Law

  • cycle time is proportional to the size of queue (WIP)
    • cycle time
      • the time from the very beginning of a task to reaching done status
      • larger WIP would mean longer cycle time
      • a way to improve efficiency is to limit WIP

Local safety

  • The local safety is the difference between the 90% confidence estimate of task time and the 50% confidence estimate of task time.
    • Remember that estimates for task time are typically a range of estimates and not a single value; think of estimates existing as a cumulative distribution function.
    • A 50% confidence estimate is essentially an aggressive estimate where the estimator only has a 50% confidence that the task will be completed within the associated time value.
    • A 90% confidence estimate is essentially a conservative estimate where the estimator has a 90% confidence that the task will be completed within the associated time value.
    • [Agile Estimating and Planning. Mike Cohn.]

Low Performing Team

  • absence of trust
  • fear of conflict
  • lack of commitment
  • avoidance of accountability
  • inattention to results

Maintainability Index

  • It is a code quality metric.
  • Maintainability Index practice
    • It is an index value between 0 and 100.
      • Maintainability is directly related to technical debt, if technical debt increases, then it will decrease maintainability of the product.
      • So make sure that the maintainability quality attribute is adressed

M

  • aslow’s Hierarchy of Needs
    • five levels of personal needs, from the fundamental at level 1 to the ultimate need at level 5
      • PhysiologicalSecuritySocialEsteemSelf Actualization
    Herzberg’s Hygiene Theory
    • satisfaction (motivators) :
      • such as recognition, achievement or personal growth
        • these are key factors to make team members motivatedsalary is not an effective motivator
      dissatisfaction (demotivators) :
      • such as bad working conditions, unfairness, etc.
      hygiene factors are factors that must be present to avoid dissatisfaction but do not provide satisfaction, also called KITA factors
      • e.g. Company policies, supervision, relationship with supervisor and peers, work conditions, salary, status, job security
    Expectancy Theory
    • an individual will decide to behave or act in a certain way because they are motivated to select a specific behavior over other behaviors due to what they expect the result of that selected behavior will befor a person to be motivated, efforts/performance/outcome must be matched – will only work hard for achievable goalskey elements of Expectancy Theory
      • Expectancy
        • extra work will be rewarded
        Instrumentality
        • good results will be rewarded
        Valence
        • the individual’s expected reward

    • Maslow’s Hierarchy of Needs

    • five levels of personal needs, from the fundamental at level 1 to the ultimate need at level 5
      • Physiological
      • Security
      • Social
      • Esteem
      • Self Actualization

    Merging

    Metrics

    • There are many code metrics, some of them measure code quality and others just prepare information about code situations.
    • See Metrics

    Metrics and Quality

    Metrics Synonyms

    Minimal Viable Product (MVP)

    • MVP is the Minimal Product (with just essential features and no more) that allows can be shipped to early adopters see and learn from the feedback instantly.
      • MVP stands for “minimum viable product” and refers to a product that has enough features to satisfy early customers and to provide feedback for future product development and enhancements.
      • The concept is somewhat similar to Minimally Marketable Feature (MMF) in which MVP is the first shippable product with the first set of MMF.

    Minimally Marketable Feature (MMF)

    • A Minimally Marketable Feature (MMF) is a software feature or product feature that is both minimal and marketable.
      • ‘Minimal’ taking the meaning of simple and small or not complex.
      • ‘Marketable’ taking the meaning of having some value, whether it is revenue generating or cost saving, that can be marketed or sold.
      • [The Art of Agile Development. James Shore.]
      • the minimal functionality set (a group of user stories or a package of features) that can deliver values (e.g. useful) to the customers / end-users
    • MMF is a distinct and deliverable feature of the system that provides significant values to the customer (can be sold / used immediately)
      • chosen for implementation after value based prioritization
      • can reap return on investment instantly

    MMF (Minimally Marketable Feature)

    • A Minimally Marketable Feature (MMF) is a software feature or product feature that is both minimal and marketable.
      • ‘Minimal’ taking the meaning of simple and small or not complex.
      • ‘Marketable’ taking the meaning of having some value, whether it is revenue generating or cost saving, that can be marketed or sold.
      • [The Art of Agile Development. James Shore.]
      • the minimal functionality set (a group of user stories or a package of features) that can deliver values (e.g. useful) to the customers / end-users
    • MMF is a distinct and deliverable feature of the system that provides significant values to the customer (can be sold / used immediately)
      • chosen for implementation after value based prioritization
      • can reap return on investment instantly

    Mocks, fakes, and stubs definitions

    • Classification between Mocks, fakes, and stubs is highly inconsistent across the literature.
      • Consistent among the literature, though, is that they all represent a production object in a testing environment by exposing the same interface.
      • Which out of mock, fake, or stub is the simplest is inconsistent, but the simplest always returns pre-arranged responses (as in a method stub).
      • On the other side of the spectrum, the most complex object will fully simulate a production object with complete logic, exceptions, etc.
      • Whether or not any of the mock, fake, or stub trio fits such a definition is, again, inconsistent across the literature.
        • For example, a mock, fake, or stub method implementation between the two ends of the complexity spectrum might contain assertions to examine the context of each call.
        • For example, a mock object might assert the order in which its methods are called, or assert consistency of data across method calls.
    • In the book “The Art of Unit Testing” mocks are described as a fake object that helps decide whether a test failed or passed by verifying whether an interaction with an object occurred.
    • Everything else is defined as a stub.
    • Fakes are anything that is not real, which, based on their usage, can be either stubs or mocks.

    Mock Object

    • In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways, most often as part of a software testing initiative.
      • A programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts.
      • The technique is also applicable in generic programming.
      • Mock objects are used to simulate the behavior of a given object in order to cope with dependencies and isolate the system under test for controlled testing.
    • For more information, it is possible to use the Test Driven Development (TDD) approach without mock objects.
    • A mock object is a type of Test Doubles.
    • See Mocks, fakes, and stubs

    Mock-up

    • Sketch, Wireframe, Mock-up and Prototypes actually represent the different stages of the design flow.
    • A Mock-up looks more like a finished product or prototype, but it is not interactive and not clickable.

    Modelling

    • Modelling is a technique for collaboratively evolving diagrams and pictures that define the problem or intended solution.
      • They are used in Agile projects to improve communication through visualisation.
    • How often models are used and their formality depends on the nature of the project and the team’s level of skill and experience in modelling techniques.
    • Models will also vary depending on the type of project, prevailing standards and best practice. In deciding what models should be created and when, the simplest rules to follow are:
      • Be able to justify the value of the model for enhancing understanding of the given subject
      • Use an approach that works for you and your organisation
      • Do enough and no more so that the purpose of the model is achieved.

    Module Coupling and Class Coupling

    • Module Coupling and Class Coupling are the same.
      • It is a code quality metric.
      • Module coupling is one of the most important metrics in software design.

    Money For Nothing & Change For Free (J. Sutherland) :

    • Contract structure starts with a standard fixed price contract that includes T&M for additional work.
    • Inserting a clause “change for free” : the customer can only use this clause if they work with the team on every iteration, failure to be engaged in such a way voids the clause and the contract reverts back to T&M.
      • Assuming the customer stays engaged , the Product Owner can reprioritize the backlog at the end of an iteration, and changes are free if the global contract work is not changed.

    MoSCoW technique

    • The MoSCoW technique is commonly used in agile to prioritize user stories and create a story map.
      • The MoSCoW technique is a DSDM technique.
      • The MoSCoW technique prioritizes user stories into the following groups in descending order of priority:
        • M – Must have;
          • Must have items are those product features which are absolutely essential to develop.
        • S – Should have;
          • Should have items are product features that are not essential but have significant business value.
        • C – Could have;
          • Could have items are product features that would add some business value.
        • W – Won’t have this time or Would have.
          • Won’t have this time items are product features that have marginal business value.
      • [User Stories Applied: For Agile Software Development. Mike Cohn.]

    Motivational Theories

    • Maslow’s Hierarchy of Needs
      • five levels of personal needs, from the fundamental at level 1 to the ultimate need at level 5
        • Physiological
        • Security
        • Social
        • Esteem
        • Self Actualization
    • Herzberg’s Hygiene Theory
      • satisfaction (motivators) :
        • such as recognition, achievement or personal growth
          • these are key factors to make team members motivated
          • salary is not an effective motivator
      • dissatisfaction (demotivators) :
        • such as bad working conditions, unfairness, etc.
      • hygiene factors are factors that must be present to avoid dissatisfaction but do not provide satisfaction, also called KITA factors
        • e.g. Company policies, supervision, relationship with supervisor and peers, work conditions, salary, status, job security
    • Expectancy Theory
      • an individual will decide to behave or act in a certain way because they are motivated to select a specific behavior over other behaviors due to what they expect the result of that selected behavior will be
      • for a person to be motivated, efforts/performance/outcome must be matched – will only work hard for achievable goals
      • key elements of Expectancy Theory
        • Expectancy
          • extra work will be rewarded
        • Instrumentality
          • good results will be rewarded
        • Valence
          • the individual’s expected reward

    Muda

    • also known as the “seven forms of waste”
      • Transportation,
      • Inventory,
      • Motion,
      • Waiting,
      • Over-production,
      • Over-processing,
      • Defects
    • Taxes are not one of the seven wastes.
      • Taxes are regulatory obligation and could not be considered as waste.
    • Muda (7 wastes) most commonly associated with Lean :
      • Transportation :
        • is there unnecessary (non-value added) movement of parts, materials, or information between processes?
      • Waiting :
        • are people or parts, systems or facilities idle – waiting for a work cycle to be completed?
      • Overproduction :
        • are you producing sooner, faster or in greater quantities than the customer is demanding?
      • Defects :
        • does the process result in anything that the customer would deem unacceptable?
      • Inventory :
        • do you have any raw materials, work-in-progress (WIP) or finished goods that are not having value added to them?
      • Movement :
        • how much do you move materials, people, equipment and goods within a processing step?
      • Extra Processing :
        • how much extra work is performed beyond the standard required by the customer?
      • Sometimes you will also hear “the disengagement of people » identified as a form of muda.
    • Muda comes in two flavors called Type-1 muda and Type-2 muda.
      • What’s the difference ?
      • In both cases it fails to meet all three criteria for value-added as defined by your customer.
        • Type I muda
          • Non-value added, but necessary for the system to function.
          • Minimize this until you can eliminate it.
        • Type II muda
          • Non-value added and unnecessary.
          • Eliminate this first!

    Mura

    • waste due to variation

    Muri

    • waste due to overburdening or stressing the people, equipment or system

    MVP (Minimal Viable Product)

    • MVP stands for “minimum viable product” and refers to a product that has enough features to satisfy early customers and to provide feedback for future product development and enhancements.
      • MVP is the Minimal Product (with just essential features and no more) that allows can be shipped to early adopters see and learn from the feedback instantly.
      • The concept is somewhat similar to Minimally Marketable Feature (MMF) in which MVP is the first shippable product with the first set of MMF.

    Naming Conventions Principle

    • Name Standards / Code Conventions make it significantly easier for developers and analysts to understand what the system is doing and how to fix or extend the source code to apply for new needs.
    • Every Sprint an Increment with one Functionality need to be produced, otherwise the Product Owner and Stakeholders won’t be able to inspect the increment accurately.
    • See Scrum and Coding Principles and Version Control, branching and Merging and Standards

    NFR (Non-Functional Requirements)

    • A Non-Functional Requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours.
      • This should be contrasted with functional requirements that define specific behaviour or functions.
      • Some examples are:
        • Accessibility
        • Audit and control
        • Availability
        • Compliance
        • Interoperability
        • Maintainability
        • Performance / response time
        • Portability
        • Resource constraints (processor speed, memory, disk space, bandwidth etc)
        • Response time
        • Scalability (horizontal, vertical)
        • Security
        • Usability
      • What is key to understanding the impact of non-functional requirements is that they are usually cross cutting concerns which impact many aspects of the application.
        • This is not a once-off story which can be completed.
        • It recurs with every new story added.

    Negotiation

    • The Agile Manifesto says collaboration over contract, negotiation communicate with two or more parties to reach an agreement and resolve conflicts
    • Negotiation as soft skill on agile projects should not have to be a winner-looser attitude. Instead, healthy negotiations allow each party to investigate the trade-offs and present alternative perspectives.
      • Negotiations are most effective where there is room for debate as room for give and take at each side.
    • Negociation is agreement found through discussion.
      • Key soft skills negotiation qualities for the effective implementation and practice of agile are: emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution, servant leadership. [Coaching Agile Teams. Lyssa Adkins.]
      • Negotiation is a key soft skill negotiation skill. It involves discussion or conversation to work towards a common understanding between two parties. [Coaching Agile Teams. Lyssa Adkins.]
    • Negotiation strategies
      • Distributive negotiation :
        • adopt extreme positions initially and work to reach a deal through tactics (the assumption is value is limited, everyone needs to fight for the best value they can get)
      • Integrative negotiation :
        • work together collaboratively to achieve greater successes by creating more values for a win-win solution (value can be created)

    Net Present Value (NPV)

    • Net Present Value (NPV) : the net future cash flow (profit – expenditure) in terms of today’s value (adjusted for future inflation, etc.);
      • a positive NPV means the project is profitable

    NPV (Net Present Value)

    • Net Present Value (NPV) : the net future cash flow (profit – expenditure) in terms of today’s value (adjusted for future inflation, etc.);
      • a positive NPV means the project is profitable

    Nexus framework

    NPV

    • Net Present Value (NPV) is a metric used to analyze the profitability of an investment or project.
      • NPV is the difference between the present value of cash inflows and the present value of cash outflows.
        • NPV considers the likelihood of future cash inflows that an investment or project will yield.
        • NPV is the sum of each cash inflow/outflow for the expected duration of the investment.
        • Each cash inflow/outflow is discounted back to its present value (PV) (i.e.,, what the money is worth in terms of today’s value).
      • NPV is the sum of all terms :
        • NPV = Sum of [ Rt/(1 + i)^t ] where t = the time of the cash flow, i = the discount rate (the rate of return that could be earned on in the financial markets), and Rt = the net cash inflow or outflow.
          • For example, consider the following two year period.
          • The discount rate is 5% and the initial investment cost is $500.
          • At the end of the first year, a $200 inflow is expected.
          • At the end of the second year, a $1,000 is expected.
          • NPV = – 500 + 200/(1.05)^1 + 1000/(1.05)^2 = ~$597.
          • If NPV is positive, it indicates that the investment will add value to the buyer’s portfolio.
          • If NPV is negative, it will subtract value.
          • If NPV is zero, it will neither add or subtract value.
      • [Agile Estimating and Planning. Mike Cohn.]
    • Select project with biggest NPV.
    • NPV = 0 when NPV finding the IRR.

    No-collocated / distributed team

    • Video conferencing, e-mail and instant messaging are technologies that can provide some level of communication in the absence of face-to-face communication. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • Video conferencing and instant messaging are technologies that can provide some level of osmotic communication. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

    Non-Functional Requirements (NFR)

    • A Non-Functional Requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours.
      • This should be contrasted with functional requirements that define specific behaviour or functions.
      • Some examples are:
        • Accessibility
        • Audit and control
        • Availability
        • Compliance
        • Interoperability
        • Maintainability
        • Performance / response time
        • Portability
        • Resource constraints (processor speed, memory, disk space, bandwidth etc)
        • Response time
        • Scalability (horizontal, vertical)
        • Security
        • Usability
      • What is key to understanding the impact of non-functional requirements is that they are usually cross cutting concerns which impact many aspects of the application.
        • This is not a once-off story which can be completed.
        • It recurs with every new story added.

    Open-closed Principle

    • O – Open-Closed Principle, this Principle affirms that an entity allows its behavior to be extended but never by modifying its source code. Any class (or whatever you write) should be written in such a way that it can be used as is.
      • It can be extended if need be, but it can never be modified.
      • Objects or entities should be open for extension but closed for modification.
    • See Scrum and Coding Principles

    Openness

    • The scrum value “openness” is often one of the primary differentiators between an average and high-performer Scrum Team.
      • It would help if you resembled the openness capability of a Scrum Team to the vast ability of a collection of openminded individuals.
      • They’re creative, innovative, intellectual, honest, direct, and humble.
    • In the scrum software engineering and delivery process, there is no inappropriate opinion, decision, and action.
      • The only condition is that they must be transparent, and they should aim to contribute to the joint mission of the Scrum Team.
      • It doesn’t mean that every decision and action must necessarily accelerate the outputs of the Scrum Team, and they should result in substantial success Product Backlog Items.
    • Thanks to openness and courage values, the scrum software development group is not afraid of making mistakes.
      • They see their errors and less than optimal outcomes as vital chances to meaningfully improve their overall productivity and quality of work.

    Optimization

    • Optimization does not necessarily imply maximization.
    • Rather, value optimization means striving to find the right balance of effectiveness, efficiency, and predictability in how work gets done:
      • An effective workflow is one that delivers what customers want when they want it.
      • An efficient workflow allocates available economic resources as optimally as possible to deliver value.
      • A more predictable workflow means being able to accurately forecast value delivery within an acceptable degree of uncertainty.
    • The strategy of Kanban is to get members to ask the right questions sooner as part of a continuous improvement effort in pursuit of these goals.
    • Only by finding a sustainable balance among these three elements can value optimization be achieved.

    Organization

    • Various grouping methods are used to organize User Stories.
      • Typical methods are :
        • 1) Relation to a product feature (e.g., all user stories that interact with the database),
        • 2) By logical sequence and dependency (e.g., Group 1 must be developed before Group 2 because of technological dependency),
        • 3) By priority based on customer value. [User Stories Applied: For Agile Software Development. Mike Cohn.]

    Organizational Agility

    • The Organizational Agility competency describes how Lean-thinking people and Agile teams optimize their business processes, evolve strategy with clear and decisive new commitments, and quickly adapt the organization as needed to capitalize on new opportunities.

    Orphan Code

    • Orphan, dead or unreachable code is a code that will never be executed.
      • It shows itself as variables that are declared but never used, functions that are never called, or code that is skipped because of a condition branch.
    • See Technical Practices

    Osmotic communication

    • Osmotic communication is a concept of communication where information is shared between collocated team members unconsciously.
      • By sharing the same work environment, team members are exposed to the same environmental sounds and other environmental input and unconsciously share a common framework that improves communication. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
      • Team members in a co-located space can overhear conversations/discussion of other members
        • the team members will be able to extract useful parts from the conversations or to join in if necessary
    • Osmotic communication includes picking up visual cues, like body language. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • Osmotic communication helps ensure the natural flow of questions, ideas, and information sharing among the agile project team. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • A core principe of the Crystal methodology is osmotic communication. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • Osmotic Communication occurs when all developers on a team are in a room at a table.
      • A discussion takes place, and members either participate or tune-out; but everyone hears or overhears what is said, and it stays in the back of their minds.
      • This works best for small teams of eight to ten people, and you need physical proximity among team members for the osmosis communication to really work.
      • Hazards of osmotic communication are too much noise and too many questions directed to the most expert developer.
        • Removing the expert to a private office for protection backfires.
        • The expert needs to be in the center of the group.
        • The expert does need to be protected, however, so he or she can get something done.
        • To accomplish this, a certain period of time should be set-up each day where the expert is totally alone and not available.
    • Agile and Crystal methodologies

    Page/Task Flow Diagrams

    • Flow diagrams define the sequence of pages or screens through which the user navigates to achieve the goal of a use case.

    Pair Programming

    • Pair Programming is the eXtreme Programming (XP) practice of two developers working at one PC to write and review code together.
      • Pair programming is a technique in Agile Software Development where two engineers share a single workstation.
        • In this technique, one engineer is the driver, who has control of the mouse and keyboard to write the code, while the other serves as the navigator, reviewing the code that the other is writing while providing tactical and analytical feedback.
        • This pair will trade‐off on these roles at regular intervals, giving each other equal chance to both execute on the work or direct it.
      • Pair programming is two developers writing code together, providing constant peer review.
      • See eXtreme Programming (XP)

    Pair Programming practice

    • Definition:
      • Pair programming is a scenario where two Developers share a single workstation and work together to develop a single feature.
    • Also Known As: Pairing, paired programming, programming in pairs
    • How it’s Used:
      • One programmer, the driver, writes the code, while the other, the navigator, reviews the code as it’s written and provides strategic direction.
        • The two programmers switch roles periodically throughout the task.
        • One or both programmers keep a running commentary during the development process.
      • For pairing to be effective, the workstation needs to be able to accommodate both programmers—at the least, the desk should have enough room to easily accommodate two chairs.
        • The room’s noise level should be controlled and should not be any louder than the muted conversation of the individual pair or multiple pairings.
    • Project Management Benefits:
      • Results in higher quality code.
      • Increases skill transfer.
      • Allows for cross-training among team members.
      • Encourages communication.
      • Clarifies problems and speeds up the decision-making process.

    Participatory decision models

    • encourage and facilitate stakeholders involvement in decision-making process through simple techniques such as :
      • simple voting
      • thumbs up / down / sideways
      • Jim Highsmith’s Decision Spectrum – pick a value among a spectrum of feeling ranging from “in favour”, “OK with reservation” to “veto”
      • fist-of-five voting – vote with 1 to 5 fingers to express the degree of agreement (i.e. 1 – totally support, 5 – object completely)
      • the simple technique will also every stakeholders to voice out their opinion with an aim to reach a consensus on the issue

    Parking lot

    • An agile practitioner can use the project parking lot and story card layout to summarize a release plan. [Agile Estimating and Planning. Mike Cohn.]

    Parking lot chart

    • A piece of paper to put important but off-topic issues / queries for later investigation / discussion, e.g. in requirement gathering
    • A parking lot chart is an agile artifact used to organize and categorize User Stories by theme.
      • A parking lot chart typically includes the name of the identified themes, the number of stories and story points it includes, and a progress chart to show the completion percentage of story points.
      • For example, a parking lot chart could have a theme of ‘database’ with 6 User Stories worth 80 story points at a 50% completion.
        • A 50% completion would indicate that 40 story points had been completed, but NOT necessarily that 3 stories had been completed because not all stories are equivalent in effort.
      • [Agile Estimating and Planning. Mike Cohn.]

    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.

    Performance Testing

    • Performance Testing is the process of determining the speed or effectiveness of a computer, network, software program or device.
      • Performance Testing needs many resources and is time-consuming.
      • So, it should ideally be carried out just before deploying to production and in an environment that, as closely as possible, replicates the production environment in which the system will ultimately run.

    Personal safety

    • Team members must be able to speak up when something is bothering them without fear of reprisal.
      • When able to speak freely a team can discover and fix its weaknesses.
      • When there is no evidence of being betrayed people tend to give out information more freely, which in turn shortens the project length.
      • A sense of personal safety is a critical property to attain on a team.
      • To gain trust there must be exposure.
      • Three things software developers must be open about in relation to the project are being able to reveal their ignorance, errors made, and any incapacity they have in meeting the requirements of an assignment.
      • Members on a team must be amiable.
      • People who are being “polite” by not being willing to show disagreement are not acting in the best interest of the team.
    • Agile and Crystal methodologies

    Personas

    • Personas
      • a tool used in requirement collection and testing in which realistic depiction of likely users for the product are created, these users can be real or fictitious
    • Personas are based on the user profile of real people (keystakeholders) or composites of multiple users.
      • When they are used as a project tool, personas should :
        • Provide an archetypal description of the users
        • Be grounded in reality
        • Be object-oriented, specific & relevant
        • Be tangible & actionable
        • Generate focus
    • Personas are not replacement for requirements, but instead they augment them.
      • This tool helps team members empathize with users of the solution.
    • Extreme Persona
      • extreme persona is persona taken to the extreme (with extreme characters / requirements) in order to identify user stories which would be missed otherwise

    Planning

    • Planning is the first step in the agile process and this is where the team measures the speed at which they can start turning stuff around.
      • The planning process is key to launching a successful iteration and retrospective.

    Planning Game

    • Definitions:
      • A Planning Game refers to a planning meeting held to decide which user stories to include in the next iteration or release.
      • 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.]
    • How it’s Used:
      • The planning game is attended by project, IT, and business stakeholders.
      • Participants select which user stories will provide the greatest business value to the product or project, given current workload estimates.
    • Project Management Benefits:
      • Increases communication between IT and business stakeholders.
      • Improves likelihood of delivering working software with each release or iteration.

    Planning poker

    • Planning poker is a popular agile game used by eXtreme Programming (XP)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.
        • each members need to select from a deck of cards (with ?, 0, 1, 2, 3, 5 …) to express their estimation of the story points for a User Story, discussion follows until a consensus is reached
      • [Coaching Agile Teams. Lyssa Adkins.]
    • This term is also known as “scrum poker” and is a consensus-based, gamified technique for estimating development goals.

    Planning poker or Scrum poker

    • Planning poker is based upon the wideband Delphi estimation technique.
      • It is a consensus-based technique for estimating effort.
      • Sometimes called scrum poker, it is a technique for a relative estimation of effort, typically in story points, to develop a User Story.
      • At a Planning poker meeting, each estimator is given an identical deck of Planning poker cards with a wide range of values.
      • The Fibonacci sequence is often used for values for planning poker (i.e., 0, 1, 1, 2, 3, 5, 8, 13, etc.).
    • A Planning poker meeting works as follows:
      • 1) a moderator, not estimating, facilitates the meeting.
      • 2) the Product Owner/manager provides a short overview of the User Story and answers clarifying questions posed by the Developers.
      • 3) Each estimator selects an estimate of work effort by selecting a card,
      • 4) Once everyone has selected a card, everyone overturns their card concurrently,
      • 5) Estimators with high and low estimates are given a chance to defend positions.
      • 6) The process repeats until there is consensus.
      • 7) The Developer who owns the User Story is typically given higher credence. [Agile Estimating and Planning. Mike Cohn.]
    • Planning poker = scrum poker

    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.]

    Pre-mortem

    • A premortem is the hypothetical opposite of a postmortem in which team members are asked to generate plausible reasons for the project’s assumed failure.
      • Premortem (rule setting, failure analysis)
      • To make it safe for team members to voice out their reservations about the plan / project direction / etc.
      • Can identify possible causes of failure which are missed during risk analysis

    Present Value (PV)

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

    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.

    Prioritization

    • In terms of Agile project management (and the PMI-ACP® exam), prioritization is the process where customers organize / select Product Backlog / User Stories for implementation based on the perceived values
    • Collaborate with stakeholders to prioritize features in order to realize value early on.
      • Review the Product Backlog priorization with stakeholder frequently to optimize value delivery.
      • Identify and prioritize continuously the various changing factors affecting the project in order to enhance quality and increase value.
      • Both value producing and risk reducing work are prioritized in into the Product Backlog in order to balance value and risks (non-value).
      • Non-functional requirements (e.g. security, operations) will need to be considered and prioritized in order to minimize the likelihood of failure.

    Prioritization Model

    • mathematical model rating benefit, penalty, cost, and risk of every proposed feature.
      • Rating 1 (low) to 9 (high), customer rates benefice (having the feature) and penalty (not having the feature), developers rate the cost & the risks, all put together in a weighted formula that is used to calculate their relative priority.

    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.

    Problem Detection

    Problem Resolution

    • The Five WHYs
      • a systematic approach to analysing identifying the root cause of a problem / cause-and-effect for the problem or issue
      • perform by repeatedly asking the question “Why” for at least 5 times until the root cause has been identified
        • imaginary example: Looking for the root cause for failing the PMI-ACP® Exam
          • Why did I fail the PMI-ACP® Exam?
            • Because I got a lower mark than the passing mark
          • Why did I get a lower mark?
            • Because I was not sure about the answers to many questions.
          • Why was I not sure about the answers to many questions?
            • Because I could not remember some facts for the exam.
          • Why couldn’t I remember some facts for the exam?
            • Because I was not familiar with the PMI-ACP® Exam content.
          • Why was I not familiar with the PMI-ACP® Exam content ?
            • Because I did not spend enough time revising the PMI-ACP® Exam notes.
        • the root cause for failing the PMI-ACP® Exam is “Because I did not spend enough time revising the PMI-ACP® Exam notes.”
    • Fishbone Diagram Analysis
      • another tool for carrying out cause and effect analysis to help discover the root cause of a problem or the bottle-necks of processes
      • aka cause and effect diagrams/Ishikawa diagrams
      • to use Fishbone diagram technique :
        • write down the problem/issue as the “fish head” and draw a horizontal line as the “spine” of the fish
        • think of major factors (at least four or above) involved in the problem/issue and draw line spinning off from the spine representing each factor
        • identify possible causes and draw line spinning off the major factors (your diagram will look like a fishbone now)
        • analyze the fishbone diagram to single out the most possible causes to carry out further investigation

    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

    Process tailoring

    • Project trade-off matrix : the project trade-off matrix classifies the constraints of scope, schedule, and cost as fixed, flexible, or accept. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

    Product Backlog

    • The Product Backlog in an Agile project is a prioritized listing of all features/User Stories for the project, the priority is usually based on the perceived value of the customer
      • 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.
      • the Product Backlog is to be created and updated by the Product Owner
        • grooming (Refinement)
          • add items based on new user stories and delete old items by considering the relative values of all tasks
          • should be “Detailed appropriately, Estimable, Emergent, Prioritized (DEEP)”
    • See Product Backlog
    • A Product Backlog is a list of the product features to be developed in a release.
      • The Product Backlog is a comprehensive list of all product features to be developed in an iteration.
      • It is an evolving document and changes to adapt to customer requirements.
      • As the project progresses, project features in the backlog become better defined as the customer understands product need more completely.
      • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
    • The Product Backlog initially serves as a rough estimate of the product’s requirements [Agile Estimating and Planning. Mike Cohn.]
      • One of the attributes of a Product Backlog is that it is EMERGENT (from the acronym DEEP).
      • It keeps evolving as time progresses.
      • It never gets frozen.
    • The Product Backlog is like a running list of all relevant tasks, features, and user stories that the team has to work on.
      • This is like a running to-do list, but it’s constantly updated and re-prioritized.
      • Items in each sprint or iteration (see terms below) are chosen from the Product Backlog.

    Product Backlog Item (PBI)

    • Definition:
      • A Product Backlog Item (PBI) is a single element of work that exists in the Product Backlog.
      • PBIs can include User Stories, epics, specifications, bugs, or change requirements.
        • The Product Owner of an Agile team compiles and prioritizes the Product Backlog, putting the most urgent or important PBIs at the top.
        • PBIs comprise tasks that need to be completed during a Scrum Sprint—a PBI must be a small enough Increment of work to be completed during a single Sprint.
        • As PBIs move up to a higher priority in the Product Backlog, they are broken down into User Stories.
    • How it’s Used:
    • Project Management Benefits:
      • Allows the team to quantify and schedule individual elements of work to be completed during a single sprint.
      • Ensures that the customer is getting the right product to meet their needs.

    Product Backlog Refinement (Grooming)

    • The Product Owner and team should be meeting at least once per sprint to prepare for future Sprints.
      • This Backlog Refinement session can also include members of the user community.
        • This group should collaborate in writing the stories for future Sprints (including decomposing larger stories into smaller ones).
      • As mentioned earlier, this collaboration is how we unlock value in a Scrum environment.
        • The ability to draw on multiple viewpoints and ideas will help to create better stories.
        • This is in stark contrast to the model of Product Owner as visionary; writing stories in isolation.
      • This moves the model away from the Product Owner arriving at the Sprint Planning meeting with a sheaf of stories for estimation towards a joint story writing workshop.
      • It is desirable for the team to estimate in this meeting as well, rather than estimating during Sprint Planning.
        • By separating the events where estimation and commitment occur, we make clear that these two are are separated conceptually as well.

    Product Champion

    • The term “product champion” to describe someone who makes the decisions about which products to create or enhance.
      • Product companies may use the term “program manager” or “product manager.”
      • IT organizations may call this role the “sponsor.”
      • Practical experience from the field suggests that the product champion role comprises a team of product managers, business stakeholders, business analysts, and client-facing personnel who are committed to providing the required service levels of feedback and validation so that the development organization can move quickly.

    Product Goal

    • The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.

    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.]

    Productivity

    • both velocity and throughout can be used to measure the productivity of a team
      • Team Velocity
        • Velocity is a capacity planning tool used in Agile project
          • usually defined as the number of story points that are completed in an iteration
        • Velocity usually increases gradually over the first few iterations as the team becomes more “performing” but stabilises afterwards as the product becomes more complicated (more bugs, more documentations, more dependencies, etc.)
      • Cycle Time and Throughput
        • Cycle time is the time necessary to get a single item of work done from start (idea) to finish (as a shippable product that delivers value)
          • Cycle time can be reduced by shortening iteration time (breaking down task sizes), limiting Work In Progress and reducing wastes
        • Throughput is the number of things that can be done in an iteration
        • Cycle Time = WIP / Throughput
          • Defect cycle time is the time between defect injection and defect remediation, the shorter the defect cycle time the better

    Product Owner

    • Definition:
      • As a member of the Agile team, the Product Owner represents the customer, and conveys the customer’s requirements and vision to the team.
        • The Product Owner writes the acceptance criteria, and prioritizes and maintains the Product Backlog.
        • Product Owners should be able to communicate well in both directions: both taking team concerns to the customer and stakeholders, and ensuring that the team stays on track to meet the customer’s vision for the product.
      • The Product Owner is ultimately responsible for translating the needs of the user into actionable development tasks.
        • The Product Owner creates User Stories that explain how features and functionality should work so that the team can complete the relevant work to make it happen.
    • How it’s Used:
      • In a Scrum environment, the Product Owner assembles and prioritizes the User Stories to be completed during a Sprint.
      • In a Kanban environment, the Product Owner assembles and prioritizes a backlog of work items to be accomplished.
        • The Product Owner has the flexibility to change and reprioritize work in the backlog at any time without affecting work already in progress.
    • Project Management Benefits:
      • Increased team understanding of customer’s vision and final product.
      • Increased communication and trust among customer, team, and stakeholders.
      • Increased support for the team from outside parties.

    Product quality

    Product roadmap

    • Product Roadmap is a visual overview of a product releases and its main components.
      • It is a communication tool that provides stakeholders with a quick view of the primary release points.
    • The Product Roadmap contains the about the schedule and cost milestones which acts as an overview of the planned releases of the project, the Product Roadmap will change over time.
    • Product Roadmap is a high level overview of the product requirements.
      • The product roadmap – owned by the Product Owner – serves as a high level overview of the product requirements.
      • It is used as a tool for prioritizing features, organizing features into categories, and assigning rough time frames.
    • Creating a product roadmap has four basic steps :
      • Identify requirements
        • these will become part of the product backlog
      • Organize requirements into categories or themes,
      • Estimate relative work effort
        • e.g., planning poker or affinity estimation) and prioritize (value)
      • Estimate rough time frames
        • estimate velocity, sprint duration, and rough release dates
    • [The Art of Agile Development. James Shore.]

    Product Vision

    • Product Vision Statement is developed by the Product Owner (with the help of the Team) to state clearly the purpose and value of the product

    Program Code

    • Program Code refers to the collection of programs that comprise the system.
      • Taken loosely, it may also include the configurations and customizations associated with vendor packages.

    Project Backlog

    • The project backlog lists all of the stories to be accomplished in the project and assigns them to sprints.

    Project Brief

    • The project brief is a document which defines the goals and objectives of the project and lists the users and candidate use cases.

    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.

    Progress

    • Of the options presented the best tool to show work in progress is a task board.
      • The User Story backlog shows what work is still remaining to be done on the project.
      • The product roadmap shows when work is planned to be completed.
      • Work breakdown structures are not commonly used on agile projects.
    • Burnup chart.
      • Burn-Up Chart is a graph that shows the progress of work toward a goal line associated with a value on the vertical axis.
      • As work is completed over time (the horizontal axis), the progress line moves up (burns up) to be nearer to the goal line.

    Progress and monitoring

    Progressive elaboration

    • Progressive elaboration is an iterative process in project management knowledge, which the details of project management plan and amount of information will increase.
      • In this process initial estimates of items such as project scope description, planning, budget, etc. will become more accurate.
      • It also helps the Project team to make the project plan with more details.

    Project buffer

    • A project buffer is extra time added to the end of a project to account for delays, obstacles, and other unforeseen issues to help predict an accurate completion date.
      • A project buffer can be estimated using several methods, three commonly used methods are :
        • Square root of the sum of squares method
          • The square root of the sum of squares method involves finding a local safety for all tasks, squaring all the local safeties, summing these squares, and then finding the square root of the sum.
          • The local safety is the difference between the 50% confidence estimate and the 90% confidence estimate.
        • Critical chain project management method (CCPM)
          • The Critical chain project management method (CCPM) is the sum of half the local safeties of all tasks.
          • The local safety is the difference between the 50% confidence estimate and the 90% confidence estimate.
        • Halving the sum of most likely estimates
          • The halving the sum of most likely estimates method involves adding all the most likely estimates and dividing by two. [Agile Estimating and Planning. Mike Cohn.
    • The agile practitioner should follow several rules of thumb when estimating a project buffer:
      • Only use a buffer if the project has more than 10 user stories,
      • The square root of the sum of squares method has shown to provide the most accurate buffer,
      • The estimate buffer should be at least 20% of the total project duration,
      • In the absence of sufficient data. like worst case scenario estimates, you can use the halving of most likely estimates to estimate a project buffer.
      • [Agile Estimating and Planning. Mike Cohn.]

    Project burndown bar chart

    • If a bar extends below the horizontal axis on a project burndown bar chart, work has been added to the project indicating an increase in scope. [Agile Estimating and Planning. Mike Cohn.]
    • If the bottom of the bar on a product burndown bar chart is above the horizontal axis, it indicates that work has been removed from the project (scope reduction) since initial planning. [Agile Estimating and Planning. Mike Cohn.]
    • The top of a bar on a product burndown bar chart may lower from one iteration to the next because the team completed work in the previous iteration or the team re-estimated user story development effort.
      • When the team completes planned work during the iteration the top of the bar chart is lowered.
      • Additionally, the top of the bar chart may be lowered if the team re-estimates user stories and finds they are not as challenging as previously believed and therefore represent a smaller story point value.
      • [Agile Estimating and Planning. Mike Cohn.]

    Project burndown chart

    • A project burndown chart is an often used information radiator to show iteration progress.
      • It charts two series: the actual work remaining and ideal/estimated work remaining.
      • The vertical axis is the work unit (often story points or hours) and the horizontal axis is iteration duration (typically in number of days).
      • The ideal/estimated work series is a straight, downward sloping line originating on the vertical axis at the value of work to be completed (e.g., 20 story points) and extending to the horizontal axis (i.e., 0 story points) on the last day of the iteration.
      • The actual series is dependent upon the agile team’s productivity and the task complexity and is updated daily.
      • The actual series is typically volatile and is not a straight line but ebbs and flows as the project team tackles the development process.
      • [Agile Estimating and Planning. Mike Cohn.]

    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.]
    • The project charter is a must-have for Agile project management to help creating a common understanding of the project objectives, mission and success criteria
      • It is the 1st documentation created for the Agile project to help kicking off the project formally
      • The project charter will be progressively elaborated as the project evolves
        • can be detailed or barely sufficient (for most cases as at the project begin, it is usually little known that what the final product will be)
      • Barely Sufficient Project Charter: usually include at least 3 elements:
        • Vision: the purpose of the Agile project – answering the “why” of the project
        • Mission: describes what will be achieved or done – answering the “what” of the project
        • Success Criteria: describe how the project will be considered a success or reach an end
    • Detailed Project Charter:
      • Background, objectives, vision (why) and mission (what), stakeholders of the project
      • Preliminary direction, scope
      • High-level budget, timeline
      • High-level risk and constraints
      • Communication plan
      • Success criteria
    • Agile charters address more about the “How” instead of “What” of the project – such that the Project Charter will not impose unnecessary boundary for the project to evolve
      • Can be in the form of an elevator statement adopting the format of :
        • For – (target customers)
        • who – (need to do what)
        • , the – (product / service)
        • is a – (product category)
        • that – (key benefits)
        • . Unlike – (competitive products)
        • , we – (primary differentiation)

    Project Initiation

    • Project foundations :
      • Project Brief or Project Charter
      • Scope definition
      • Use case discovery
      • Page Flow Diagram
      • Select Definitions and approach
      • Staffing confirmation
      • Workspace Preparation
    • Requirements Analysis :
      • Case dependent mix of:
        • Use case analysis
        • System requirements
        • Business rules
        • SME (Subject Matter Expert) interviews
    • Design Analysis :
    • Technical Analysis
      • Case dependent mix of:
        • Languages/Tools
        • Systems Architecture
        • Database Design
        • Integration Design
        • Infrastructure Design
    • Project Plan Update :
      • Vision
      • Initial Product Backlog
        • Story definition
        • Story estimation
        • Story prioritization
      • Initial Product Roadmap
        • Sprint assignment
        • Release Plan

    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.

    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.

    Prototypes

    • Sketch, Wireframe, Mock-up and Prototypes actually represent the different stages of the design flow.
    • A Prototype has a maximum level of fidelity and is interactive and clickable.
    • Prototypes are low cost, low risk methods to portray a design idea to a customer in order to obtain feedback before development.
      • Although time consuming and having cost, prototypes can help save later costs that may occur if a design is not modeled beforehand to obtain feedback and fails to meet customer expectations. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • In the agile design process, prototypes help the customer understand current design state.
      • Three common types of prototypes are HTML, paper (i.e., sketches), and wireframes.
        • Wireframe
          • A wireframe is a sketch of a user interface, identifying its content, layout, functionality, is usually black and white, and excludes detailed pictures or graphics.
          • A wireframe can be created on paper, whiteboards, or using software. [Agile Estimating and Planning. Mike Cohn.]
        • HTML
          • HTML and other software based solutions are ideal for presenting prototypes to customers, especially when off site.
          • Software based prototypes are dynamic, graphic capable, and portable.
          • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
        • Maquette
        • See Sketch, Wireframe, Mockup and Prototype

    Prototypes, Simulations & Demonstrations

    • Demonstrations are critical to confirm success on software projects.
      • I Know It When I See It (IKIWISI), is most of the time the most valuable tool for accepting the new functionality in its environment.
      • In addition of helping clarify requirements, demonstrations can uncover the need for new features
      • Requirements evolve with prototypes & demonstrations. Giving end-users a chance to evaluate helps uncover the true business requirements

    PV (Present Value)

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

    Quality standards

    • Refined over time
    • Agile efforts have project and quality Standards that the team defines collaboratively at the beginning of an effort and refines collaboratively throughout the effort.
    • Project and quality Standards help an agile team with team cohesion and provide a structure, albeit one that can adapt as the project evolves, to promote a self-disciplined environment.
      • There is no ‘one size fits all’ Standards definition in agile; because every project is different, it has been shown that the team should define which project and quality standards it should hold itself against and strive to conform to those Standards while also being open to adapting those standards throughout the project to optimize performance and delivered value.
      • Project Standards can range from where the Daily Stand-up meeting is located and how long each participant has to share his or her progress and challenges to highly specific software coding styles, methods for test-driven development, and what the team’s definition of ‘done-done’ means.
      • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • Quality standards can be governed by contract or internally enforced :
      • Automating as many test possible
      • Testing occurs as part of every iteration
      • Try to fix at least 90% of the defects within the next iteration

    Rainy Day Testing

    • Sad Pass Testing (Unhappy Pass, Rainy Day)
    • There is no agreed name for the opposite of happy paths : they may be known as sad paths, bad paths, or exception paths.
      • The term ‘unhappy path’ is gaining popularity as it suggests a complete opposite to ‘happy path’ and retains the same context.
      • Usually there is no extra ‘unhappy path’, leaving such ‘term’ meaningless, because the happy path reaches the utter end, but an ‘unhappy path’ is shorter, ends prematurely, and doesn’t reach the desired end, i.e. not even the last page of a wizard.
      • And in contrast to a single happy path, there are a lot of different ways in which things can go wrong, so there is no single criterion to determine ‘the unhappy path’.
    • See Scrum and Coding Principles

    Ranking / Relative Prioritization

    • an ordered list of all User Stories / features to be completed with 1 being the highest priority in the Product Backlog
      • when new features are to be added, it has to be compare, in terms of priority, to all current features
      • the schemes list above can be used to assist the relative prioritization / ranking tasks
    • 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.]

    Ready

    Refactoring

    • Definitions:
      • Refactoring code means to improve, clarify, and streamline the internal structure of existing code without affecting its external behavior. Refactoring does not include rewriting code or fixing bugs.
        • The noun “refactoring” refers to specific, finite methods for refactoring code, such as using Extract Method to clarify the purpose of a piece of code.
      • Refactoring is a technique used in programming project to review codes, re-organize and simplify the code without changing the behavior for easier maintenance
        • 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.]
    • How it’s Used:
      • Refactoring is used in Agile to maintain code clarity and extensibility between sprint iterations.
    • Project Management Benefits:
      • Keeps code clean and easy to read.
      • Prevents code duplication.
      • Makes bugs easier identify and fix.
      • Makes code easier to maintain and extend.
    • See Test Driven Development (TDD) and eXtreme Programming (XP)

    Reference point user story

    • The reference point User Story for planning poker is typically a medium or average size User Story.
      • Estimators can use the reference point to make relative estimations. [Agile Estimating and Planning. Mike Cohn.]

    Refinement

    • see Product Backlog Refinement

    Reflection

    • During reflection an agile team takes a break after completing an iteration to pause and contemplate about its performance.
      • Topics include
        • Lessons learned from successes and failures, such as programming methods that were highly efficient or inefficient;
        • how to reinforce successful practices, such as new testing standard practices;
        • how to discourage negative practices, like straying from team approved coding standards in order to make an iteration deadline.
        • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

    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.]

    Reflective improvement

    • Crystal Clear is not prescriptive and leaves many things up to the team to reflect on and finalize after discussion.
      • Experimentation is a key element in Crystal Clear.
    • Agile and Crystal methodologies

    Reflective improvement workshop

    • Sprint Retrospective are reflexive improvement workshops :
      • Reflective improvement workshops are a cornerstone of the Crystal methodology.
        • While all agile methodologies incorporate reflection into their standard practices, Crystal terms the practice ‘reflective improvement workshops.’
        • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
        • Setting the stage for a retrospective means creating a safe environment that is open and honest. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
    • Agile and Crystal methodologies

    Regression Testing

    • Regression Testing is the process of testing changes to computer programs to make sure that the older programming still works with the new changes.
    • Regression Testing :
      • Whenever developers change or modify their software, even a small tweak can have unexpected consequences.
      • Regression Testing is testing existing software applications to make sure that a change or addition hasn’t broken any existing functionality.
    • Regression Testing purpose is to catch bugs that may have been accidentally introduced into a new build or release candidate, and to ensure that previously eradicated bugs continue to stay dead.
      • By re-running testing scenarios that were originally scripted when known problems were first fixed, you can make sure that any new changes to an application haven’t resulted in a regression or caused components that formerly worked to fail.
      • A Regression test can be automated.
    • In Regression Testing before a new version of software is released, the old test cases are run against the new version to make sure that old capabilities still work.

    Regular communication

    • An agile approach heavily emphasizes the need for direct customer involvement to ensure product quality and value.
      • One way to promote customer engagement is to have regular communication between the customer and team.
      • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

    Relatif ranking

    • Regardless of other prioritization scheme the relative ranking is used to be answered by the business and will provide a hard ranking proposed by the business model of the tool to be applied.
      • Provides a framework for deciding if and when to incorporate changes, if those changes are effective to business

    Relative Estimation

    • Definition:
      • Relative estimation is one of several types of estimations Agile teams use to determine the amount of effort needed to complete project tasks.
        • User Stories are compared against equivalent, previously completed tasks or group of tasks of similar difficulty.
      • Also Known As: Silent grouping, affinity testing
    • How it’s Used:
      • Agile teams use relative estimation to assess time and effort needed to complete a task or User Story based on how long a similar task took to complete.
      • Teams often use a non-numerical scale to compare tasks, such as tee-shirt sizing, where task effort is assessed as extra-small, small, medium, large, or extra-large.
    • Project Management Benefits:
      • Provides accurate estimates for release dates and future forecasting.
      • Eliminates time wasted on precision estimations.
      • Eliminates confusion between estimates and commitments.
      • Leads to increased customer satisfaction.

    Relative Prioritization / Ranking

    • an ordered list of all User Stories / features to be completed with 1 being the highest priority in the Product Backlog
      • when new features are to be added, it has to be compare, in terms of priority, to all current features
      • the schemes list above can be used to assist the relative prioritization / ranking tasks
    • 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.]

    Relative Sizing

    • Agile project management makes use of relative sizing (e.g. story points) as opposed to the use of exact units like money and time in traditional project management for estimation as Agile projects are more prone to changes, making use of relative sizing will be more flexible yet still give a reference for meaningful estimation

    Relative sizing/story points

    • Agile project management makes use of relative sizing (e.g. story points) as opposed to the use of exact units like money and time in traditional project management for estimation as Agile projects are more prone to changes, making use of relative sizing will be more flexible yet still give a reference for meaningful estimation
      • Agile teams typically use story points to estimate the relative size or effort of developing a User Story [Agile Estimating and Planning. Mike Cohn.]
    • Agile teams should agree to one method of estimation, either story points or ideal days, as both use different units of measurement and can lead to confusion. [Agile Estimating and Planning. Mike Cohn.]
    • Instead of using story points, agile teams may estimate the relative sizes of user stories using ideal days.
      • Ideal days represents the amount of days – uninterrupted by meetings, personal life, non-working days, or any other delays, obstacles or distractions – that it would take a single person to build, test, and release the User Story, relative to other User Stories in the Product Backlog. [Agile Estimating and Planning. Mike Cohn.]
    • Both Planning poker and affinity estimation are agile techniques used to size the work effort of developing User Stories. [Agile Estimating and Planning. Mike Cohn.]

    Release on Demand (Continuous Delivery)

    Release Plan

    • Release Plan
      • responsible by the customer / Product Owner with the help of project team in release planning to document the availability of features over time, subject to changes depending on actual progress / change requests

    Release planning

    • Release planning helps the customer and agile team determine what should be developed during each project timeframe or phase, and when a product will ideally be ready for release. [The Art of Agile Development. James Shore.
      • Planning for a release occurs during release planning. [The Art of Agile Development. James Shore.]
      • In release planning, the agile project manager discusses the product vision with the development team in detail.
        • This ensures that the proper requirements, acceptance criteria, and priorities are established. [The Art of Agile Development. James Shore.]
        • For new product development projects, it’s good to plan at least 5 adaption points in a release, we analyze the performance at the end of iteration so we should have some minimum number of iterations which helps us in adapting based on the discovery we make at iteration end.

    Requirements Prioritization Model

    • mathematical model rating benefit, penalty, cost, and risk of every proposed feature.
      • Rating 1 (low) to 9 (high), customer rates benefice (having the feature) and penalty (not having the feature), developers rate the cost & the risks, all put together in a weighted formula that is used to calculate their relative priority.

    Requirements Register

    • The requirements register lists all system requirements.

    Requirements Review

    • a group of users and/or recognized experts carrying out reviews on the documented requirements to ensure that:
      • requirements accurately reflect the needs and priorities of stakeholders
      • requirements are technical feasible to be fulfilled

    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.

    Respect

    • Regardless of their age, gender, race, belief, experience, competence, opinions, and work performance, every member of a Scrum Team must respect and count on each other.
      • This respect is not only confined within the boundary of the Scrum Team.
      • Moreover, every internal or external IT and business Stakeholder who interacts with the Scrum Team is utterly respected and welcomed by a Scrum Team.
      • Experienced team members must pay attention in order not to invalidate the willingness of the contribution from less experienced team members.
      • It’s particularly crucial to properly receive and answer opposite opinions that the majority of the group do not agree with.

    Retrospective

    • At the end of each iteration, the team will usually hold a retrospective meeting.
      • This meeting is meant to assess the work that was done in the previous iteration, identify any challenges, and make adjustments to the work process.
    • 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.
    • Retrospective is an Agile process for self-evaluation to be performed at the end of each iteration (somehow similar to the “postmortem” meeting or “lessons learned” meeting in traditional project management)
      • a continuous process improvement for timely implementation
      • involved the Developers only with a timebox of up to 1 hour
      • a valuable learning opportunity for the Agile team
      • analyze, adapt and improve the entire development process
      • improve productivity, capability, quality and capacity
      • actionable improvement tasks are to be implemented right in the next iteration
      • for instant improvements
      • focus on what went well, what went wrong and how the team can improve in next iteration and beyond without finger-pointing
      • typical agenda :
        • set the stage
          • get people comfortable to speak and outline the topics for discussion
        • check-in
          • everyone express in 1 or 2 words about the expectation of the retrospective
        • focus on / focus off
          • which side to focus on (e.g. dialogue vs debate)
        • ESVP
          • choose 1 from among “explorers, shoppers, vacationers and prisoners” that describes their feeling anonymously
        • working agreements
          • work on different topics in small groups first
        • gather data
        • generate insights
        • decide what to do
          • identify the high priority items to devise an action plan
        • close the retrospective
          • express appreciation and feelings
        • Plus / Delta
          • what should be done more / what should be changed
        • Helped, Hindered, Hypothesis
          • three flip charts for participants to add ideas on
        • the improvement stories chosen in the retrospective will treated as non-functional backlogs

    Retrospective Meeting vs Lessons Learned Meeting

    • Retrospective meeting is carried out once per iteration and identifies areas for improvement
    • Lessons Learned meeting is carried out once at the end of the project / phrase as the project closure activity and all the lessons learned are to be identified and documented (according to PMBOK® Guide) for future references (not as a feedback to the project itself)

    Retrospective Meeting vs Review Meeting

    • Retrospective meeting is for the Developers only with the primary aim for process improvement
    • Review meeting is for demonstration / getting acceptance of deliverables with management, Product Owner and stakeholders

    Return on Investment (ROI)

    • Return on Investment (ROI) – the values a project realized (using present value) compared to the investment; a positive ROI means the project is profitable.
    • Return on Investment (ROI) is a metric used to evaluate the efficiency of an investment or to compare efficiency among a number of investments.
      • To calculate ROI, the return of an investment (i.e., the gain minus the cost) is divided by the cost of the investment.
      • ROI = (Benefit – Cost)/Cost
      • The result is usually expressed as a percentage and sometimes a ratio.
      • The Product Owner is often said to be responsible for the ROI.
        • One of the key responsibilities of the Product Owner is the return on investment.
      • [Agile Estimating and Planning. Mike Cohn.]
    • Select project with biggest ROI.

    Revenue

    • Additional revenue
      • Additional revenue is revenue realized through the sales of new product features or services to existing customers. [Agile Estimating and Planning. Mike Cohn.]
    • Retained revenue
      • Retained revenue is revenue retained through the development of new product features or services that prevent existing customers from stopping use of the existing product. [Agile Estimating and Planning. Mike Cohn.]
    • New revenue
      • New revenue is revenue realized through the sales of products or services to new customers. [Agile Estimating and Planning. Mike Cohn.]

    RICE

    • RICE stands for Reach, Impact, Confidence and Effort.
      • It’s a simple weighted score method for quantifying the potential value of features, project ideas and initiatives.
      • A RICE score helps product managers quantify the estimated value of a feature or project idea so they’re easier to sort when it’s time to decide the order they should be worked on.
      • Sean McBride, who co-developed RICE prioritization as a PM at Intercom, walked us through how to best use this prioritization method (read it here).

    Risks

    • The agile methodology generally deals with qualitative risks, not quantitative. [The Art of Agile Development. James Shore.]
      • Agile team follows Qualitative Risk analysis.
      • Quantitative risk analysis usually involves calculation of risk impact in monetary terms like Expected Monitory Value.
    • Whole team is responsible for managing risk.
    • This must have made you wonder then how come Project manager role.
      • It is important here to note that here we are not talking about agile and XP does recognize the role of Project Manager.
      • The overall risk management responsibility can be assigned to Project Manager.

    Risk-adjusted backlog

    • A risk-adjusted backlog is a Product Backlog organized by taking into account risk.
      • risk can be estimated as the product of severity/consequence and likelihood.
      • The product backlog would be re-prioritized with the help of risk analysis input from the team and stakeholders to balance the “risk vs value” factor (as risks are “de-value”)
    • risks are usually considered to be possible negative impacts (though there are many possible positive impacts)
    • User Stories can also be positioned on a risk-to-value matrix to help prioritize them in the backlog.
      • The risk-to-value matrix is a chart with four quadrants.
        • Along the horizontal axis is value in ascending order.
        • Along the vertical axis is risk in ascending order.
        • A User Story that is high risk and high value is located in the top-right corner.
        • A User Story that is low risk and high value is located in the lower-right corner.
        • A User Story that is low risk and high value is located in the lower-right corner.
        • A User Story that is low risk and low value is located in the lower-left corner.
    • Typically a team will prioritize high-value, low-risk user stories first, followed by high-value, high-risk User Stories, followed by low-value, low-risk user stories, followed by low-value, high-risk user stories. [The Art of Agile Development. James Shore.]
    • New identified risk
      • Bring the newly identified risk to the team’s attention and to discuss its impact. [The Art of Agile Development. James Shore.] [Risk management]

    Risks areas

    • 5 core risks areas :
      • Productivity variation (difference between planned and actual performance)
      • Scope creep (considerable additional requirements beyond initial agreement)
      • Specification breakdown(lack of stakeholder consensus on requirements)
      • Intrinsic schedule flaw (poor estimates of task durations)
      • Personnel loss (the loss of human resources).
    • [The Software Project Manager’s Bridge to Agility. Michele Sliger, Stacia Broderick.]

    Risk Adjusted Backlog

    • Prioritization criteria for Product Backlog :
      • value, knowledge, uncertainty, risk
    • Product Backlog can be re-prioritized by Product Owner as needed to reduce risks while still realizing values
      • The Product Owner can give each feature / risk response actions (non-functional requirements) on the backlog a value by, for features, assessing ROV and, for the case of risks, the costs involved (by multiplying the probability of the risk in %)
      • The Product Backlog of features and risk response activities can then be prioritized based on the dollar values
      • Risk adjustment tries to identify and mitigate the risk at an early stage of development
      • ‘Fail fast’ allows the team to learn and adjust course

    Risk audit

    • A risk audit is typically performed in the iteration review after each iteration. [The Art of Agile Development. James Shore.]

    Risk–based spike

    • Risked-based Spike is a risk management technique and is often thought of as a task.
      • A risked-based Spike is a task used to gain knowledge in an area of uncertainty to reduce risk.
      • For example, Developers may need to understand how migrating from Windows 7 to Windows 8 may impact the look and feel of the interface.
      • Risked-based Spikes typically are included in iteration planning directly before a the task that holds the uncertainty.
      • [The Art of Agile Development. James Shore.]

    Risk burn-down graphs

    • to show the risk exposure of the project
      • created by plotting the sum of the agreed risk exposure values (impact x probability) against iterations
      • to be updated regularly (per iteration) to reflect the change in risk exposure
      • general recommendation: top 10 risks are included
      • the risk burn down chart should have the total risks heading down while the project progresses
    • A project manager may use a Burn-Down Chart and a team’s Velocity to make sure the team is not under or over committing to an iteration.
      • A sustainable pace of development is an important facet of agile project planning and risk management. [The Art of Agile Development. James Shore.]
    • A risk burndown chart is a risk management technique used to track project risk over time.
    • It allows stakeholders to quickly review project risk management performance (e.g., increasing, decreasing, and by how much) over time.
      • Severity (a product of impact and probability) is charted along the vertical axis with time on the horizontal axis.
      • Impact typically takes a value from 0 to 5 in increasing order of risk and probability/likelihood typically takes a value from 0 to 5 in increasing order of probability.
      • In this example, the worst severity a risk could have is 25 (5 × 5 = 25) and the least harmful severity a risk could have is 0.
      • The agile team and customer/product owner identifies its risks and assigns severity values in a risk register and tracks those values over time. Ideally, risk severity will decrease over time.
      • [The Art of Agile Development. James Shore.]
    • As we progress into the project we map our effectiveness of dealing with those identified risks in a burn down chart.

    Risk-based burn-up chart

    • A risk-based burn-up chart tracks targeted and actual product delivery progress and also includes estimates of how likely the team is to achieve targeted value adjusted for risk.
      • includes estimates of how likely the team is to achieve targeted value adjusted for risk by showing the optimistic, most likely and the worst-case scenario
    • Typically, risk is shown as three different levels: best-case; most likely; and worst-case.
      • For example, if you have a 10 iteration project and the team’s current velocity is 10 story points, you can portray the chance of completing 100 story points (most likely case), the chance of completing 80 story points (worst-case), and the chance of completing 120 story points (best-case).
      • In this way, the stakeholders get a feel for the range of risk.
      • [The Art of Agile Development. James Shore.]

    Risk based spike

    • Spike is a rapid time-boxed experiment (by the developers) to learn just enough about the “unknown” of a user story for estimation / establishing realistic expectations / as a proof of concept
      • the “unknown” can be: new technologies, new techniques
      • can be a “proof of concept”
      • Spikes are carried out between sprints and before major epics / user stories
      • products of a spike are usually intended to be thrown away
      • types for eXtreme Programming (XP) :
        • Architectural Spike :
          • associated with an unknown area of the system, technology or application domain
        • non-architectural spike:
          • others
        • Risk based spike:
          • a Spike to allow the team to eliminate or minimize some major risks
          • if the Spike fails for every approach available, the project reaches a condition known as “fast failure”, the cost of failure is much less than failing later
    • A spike solution, or Spike, is a technical investigation.
      • It’s a small experiment to research the answer to a problem.
      • For example, a programmer might not know whether Java throws an exception on arithmetic overflow.
        • A quick ten-minute spike will answer the question.
      • See Agile risk and spike

    Risk Burn Down Graphs / Charts

    • to show the risk exposure of the project
      • created by plotting the sum of the agreed risk exposure values (impact x probability) against iterations
      • to be updated regularly (per iteration) to reflect the change in risk exposure
      • general recommendation :
        • top 10 risks are included
    • the risk burn down chart should have the total risks heading down while the project progresses

    Risk contingency

    • A contingency activity is an activity ready for implementation to reduce risk impact should a risk occur. [The Art of Agile Development. James Shore.]
      • Team is keeping some contingency reserve to take care of unexpected tasks it falls in Contain.
      • In contain, we plan contingency reserve to take care of risk.

    Risk Management

    • Risk is uncertainty that could affect the success/failure of the project.
      • Risks become problems or issues once they actually occur.
    • Risks can be threats or opportunities, negative project risks are considered as “anti-value”.
      • In order to maximize values, negative risks must be minimized while positive risks should be utilized.
      • But once problems or issues arise, they must be resolved timely in order to reduce effects on value creation.
    • Risk identification should involve the customer, project team and all relevant stakeholders
      • Five Core Risks mentioned in the book “The Software Project Manager’s Bridge to Agility” :
        • productivity variation (difference between planned and actual performance)
        • scope creep
          • considerable additional requirements beyond initial agreement
        • specification breakdown
          • lack of stakeholder consensus on requirements
        • intrinsic schedule flaw
          • poor estimates of task durations
        • personnel loss
          • the loss of human resources
      • Risks are assessed by risk probability (how likely it occurs) and risk impact (how severe the risk impact is):
        • Risk Severity = Risk Probability x Risk Impact
          • Risk probability can be a percentage value or a number on a relative scale (the higher the more likely)
          • Risk impact can be dollar value or a number on a relative scale (the higher the more costly to fix)
        • As a general rule, “riskier” features (with high values) should be tested in earlier sprints to allow the project to “fail fast” as failing during the earlier phrase of the project is much less costly than failing during a later phrase
        • Risk is high at the beginning of the project (both for traditional and Agile projects) but Agile projects have higher success rates as the very nature of Agile project management tends to reduce risks as changes are inherent to the projects
        • Risk can be categorized into the following:
          • Business
            • related to business value
          • Technical
            • about technology use and/or skill sets
          • Logistic
            • related to schedule, funding, staffing, etc.
          • Others
            • Political, Environmental, Societal, Technological, Legal or Economic (PESTLE)
        • To tackle risks:
          • Identify Risks -> Assess Qualitatively and Quantitatively -> Plan Response -> Carry Out Responses Should Risks Arise -> Control and Review
      • Risk Adjusted Backlog
        • Prioritization criteria for backlog: value, knowledge, uncertainty, risk
          • Product Backlog can be re-prioritized by Product Owner as needed to reduce risks while still realizing values
          • The Product Owner can give each feature / risk response actions (non-functional requirements) on the backlog a value by, for features, assessing ROV and, for the case of risks, the costs involved (by multiplying the probability of the risk in %)
          • The Product Backlog of features and risk response activities can then be prioritized based on the dollar values
          • Risk adjustment tries to identify and mitigate the risk at an early stage of development
            ‘Fail fast’ allows the team to learn and adjust course
      • Risk Burn Down Graphs / Charts
        • to show the risk exposure of the project
          • created by plotting the sum of the agreed risk exposure values (impact x probability) against iterations
          • to be updated regularly (per iteration) to reflect the change in risk exposure
        • general recommendation: top 10 risks are included
          • the risk burn down chart should have the total risks heading down while the project progresses
      • Risk-based Burn Up Chart
        • tracks the targeted and actual product delivery progress
        • includes estimates of how likely the team is to achieve targeted value adjusted for risk by showing the optimistic, most likely and the worst-case scenario
      • Risk-based Spike
        • Spike a rapid time-boxed experiment (by the developers) to learn just enough about the “unknown” of a user story for estimation / establishing realistic expectations / as a proof of concept
          • the “unknown” can be: new technologies, new techniques
          • can be a “proof of concept”
          • spikes are carried out between sprints and before major epics / user stories
          • products of a spike are usually intended to be thrown away
          • Spike types eXtreme Programming (XP) :
            • Architectural Spike :
              • associated with an unknown area of the system, technology or application domain
            • non-architectural spike:
              • others
            • Risk based spike:
              • a spike to allow the team to eliminate or minimize some major risks
          • if the spike fails for every approach available, the project reaches a condition known as “fast failure”, the cost of failure is much less than failing later

    Risk mitigation

    • Generally, risk mitigation is thought of as the reduction of the impact whether or not the risk occurs. [The Art of Agile Development. James Shore.]

    Risk monitoring

    • Risk is continuously monitored on an agile project through information radiators, daily stand-up meetings, iteration reviews, and iteration retrospectives. [The Art of Agile Development. James Shore.]
      • Through information radiators, daily stand-up meetings, iteration reviews, and iteration retrospectives.
      • In other words, risk is monitored and controlled throughout an agile project and in many different ways.
      • [The Art of Agile Development. James Shore.]

    Roadmap

    • A high level overview of the product requirements.
      • The product roadmap – owned by the Product Owner – serves as a high level overview of the product requirements.
      • It is used as a tool for prioritizing features, organizing features into categories, and assigning rough time frames.
    • Creating a product roadmap has four basic steps :
      • 1) Identify requirements (these will become part of the product backlog),
      • 2) Organize requirements into categories or themes,
      • 3) Estimate relative work effort (e.g., planning poker or affinity estimation) and prioritize (value), and
      • 4) Estimate rough time frames (estimate velocity, sprint duration, and rough release dates).
    • [The Art of Agile Development. James Shore.]

    ROI

    • Return on Investment (ROI) – the values a project realized (using present value) compared to the investment; a positive ROI means the project is profitable.
    • Return on Investment (ROI) is a metric used to evaluate the efficiency of an investment or to compare efficiency among a number of investments.
      • To calculate ROI, the return of an investment (i.e., the gain minus the cost) is divided by the cost of the investment.
      • ROI = (Benefit – Cost)/Cost
      • The result is usually expressed as a percentage and sometimes a ratio.
      • The Product Owner is often said to be responsible for the ROI.
        • One of the key responsibilities of the Product Owner is the return on investment.
      • [Agile Estimating and Planning. Mike Cohn.]
    • 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.
    • Waves or phases, only the next few iterations are planned in detail.
      • The iterations more distant are planned only at a high-level.
      • Rolling wave planning (or rolling look ahead planning) involves planning in waves or phases and is especially useful for large, complex projects.
      • Only the next few iterations are planned in detail and iterations more distant are planned only at a high-level.
      • [Agile Estimating and Planning. Mike Cohn.]

    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

    Sad-pass Testing

    • Sad Pass (Unhappy Pass, Rainy Day)
    • There is no agreed name for the opposite of happy paths : they may be known as sad paths, bad paths, or exception paths.
      • The term ‘unhappy path’ is gaining popularity as it suggests a complete opposite to ‘happy path’ and retains the same context.
      • Usually there is no extra ‘unhappy path’, leaving such ‘term’ meaningless, because the happy path reaches the utter end, but an ‘unhappy path’ is shorter, ends prematurely, and doesn’t reach the desired end, i.e. not even the last page of a wizard.
      • And in contrast to a single happy path, there are a lot of different ways in which things can go wrong, so there is no single criterion to determine ‘the unhappy path’.
    • See Scrum and Coding Principles

    SAFe : The Scaled Agile Framework for the Lean-Agile Enterprise

    • The Scaled Agile Framework (abbreviated as SAFe), is a set of organization and workflow patterns intended to guide enterprises in scaling Lean and Agile practice.
      • Along with Large-Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), and Nexus, SAFe is one of a growing number of frameworks that seek to address the problems encountered when scaling beyond a single team.
      • SAFe is made freely available by Scaled Agile, Inc., which retains the copyrights and registered trademarks.
      • © Scaled Agile, Inc.

    Sandbox Testing

    • Sandbox Testing is a type of integration test.
      • Sandbox Testing can be used for independent evaluation, monitoring or testing.
      • Sandbox Testing is a type of software testing environment isolated from the production or live environment.
        • It is known also a test server or development server.
      • A sandbox is a type of software testing environment that enables the isolated execution of software or programs from the production or live environment for independent evaluation, monitoring, or testing.
        • In an implementation, a sandbox also may be known as a test server, development server, or working directory.

    Scaled Scrum

    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.

    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.

    Scout Rule

    • The practice of always leaving the code base in a little better state than it was found before modifications, is called the Scout Rule. Scout Rule is a mean to progress towards Clean Code.
    • See Scrum and Coding Principles

    Scrum

    • Scrum is a specific agile methodology.
      • It’s often seen as the de facto agile development structure, but not the only one.
    • Scrum is an agile framework popularized by Jeff Sutherland, Ken Schwaber and others employing 15 to 30 day Sprints (iterations) and minimalist controls.
      • Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems as defined in the Scrum guide.

    Scrum and Technical Practices

    Scrum approach

    • Scrum has an iterative-incremental approach to software development and the focus is on shippable software at the end of every Sprint :
      • In the domains of software design and architecture this leads to a major shift, i.e. from prescriptive and upfront to emergence.
      • Designs and architectures grow and change as applications and products grow and change.

    Scrum Board

    Scrum communication model

    • The Scrum Commucation Model is :
      • Product Owner communicates with Customers and Stakeholders
        • The Product Owner’s main focus of communication should be with dev, customers (who pay the bill) and other stakeholders who may have an interest in the product.
        • Ensuring that their voices are heeded in the development of the product is vital to ensure the successful outcome.
        • All the real benefits of agile are realised through collaboration”, the Product Owner’s collaboration with customers, stakeholders and the team are the key to unlocking this value.
        • In the day-to-day Sprint activities it is vital that the Product Owner is available to answer the Developers’s questions and requests for clarification.
      • Scrum Master with Developers, Product Owner and Management
      • Developers with Users
        • The Developers should as far as possible communicate directly with the user community.
        • Sometimes this may be the same as the customer (if you are dealing with a direct customer facing product).
        • However, where this is not the case (as in many enterprise scale applications) having the Product Owner as a proxy or conduit for information from users is not advised.
        • Face-to-face interaction (or at least direct communication) between the user community and the Developers reduce the likelihood for miscommunication.

    Scrum framework

    Scrum guide

    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.

    Scrum Team definition :

    Scrum Team development

    Scrum Testing and practices

    Scrum Values

    • Scrum Values is a set of fundamental values and qualities underpinning the Scrum framework; commitment, focus, openness, respect and courage.

    Self-Managing

    • Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.
      • They are also self-managing, meaning they internally decide who does what, when, and how.
      • See Scrum Self-Organization

    Self-Organization

    Self-organization and Empowerment

    • Self-Organizing teams are the foundation for Agile project management
      • Self-Organization includes:
        • team formation,
        • work allocation (members are encouraged to take up works beyond their expertise),
        • self management,
        • self correction
        • and determining how to work is considered “done”
      • Agile team is given the power to self-direct and self-organize by making and implementing decisions, including:
        • work priority, time frames, etc
        • as they believe “the best person to make the decision is the one whose hands are actually doing the work”
      • In Agile projects, the project manager/Coach/Scrum Master practice servant leadership to remove roadblocks and obstacles and to enable the team to perform best

    Servant leadership

    • Servant leadership has its roots with an essay written in 1970 by Robert K Greenleaf.
      • Greenleaf defined servant leaders as humble stewards devoted to their company and work to serve their peers, teams, and customers.
      • In a self-organizing team, a servant leader, as Greenleaf defined it, is ideal as the team leader is an enabler, listening to the agile team’s needs, removing obstacles, and providing tools or other support to promote high productivity. [Coaching Agile Teams. Lyssa Adkins.]
    • Servant leader is an expected leadership style from Scrum master.
      • In high performance teams, leaders manage the principles and principles manage the teams.
      • [Becoming Agile: …in an imperfect world. Greg Smith, Ahmed Sidky.]

    Servant Leadership (Agile Leadership Style)

    • traditional leadership and management emphasizes on command-and-control
      • i.e. Theory X – workers are lazy and need to be monitored closely
    • servant leaders will lead by serving to ensure the needs of team members are met and roadblocks are cleared
      • [i.e. servant first, leader second mentality] (Theory Y – team members are self-motivated)
    • an Agile servant leader needs to :
      • communicate and re-communicate project vision
        • maintain a common vision to drive the team to perform
      • protect the team from interference, distractions and interruptions
      • remove impediments to the team’s performance
      • carry food and water
        • i.e. provide all the resources for the team to perform, including motivate the team, provide trainings

    Servant Leadership principles

    • 12 principles :
      • Learn the team members’ needs
      • Learn the projects requirements
      • Act for the simultaneous welfare of team & project
      • Create an environment of functional accountability
      • Have a vision of the completed project
      • Use the project vision to drive your own behavior
      • Serve as the central figure in successful team development
      • Recognize team conflict as a positive step
      • Manage with an eye towards ethics
      • Ethics is an integral part of our thinking
      • Take time to reflect on the project
      • Develop backwards thinking (What if ?)

    Service Level Expectation (SLE)

    • The Service Level Expectation (SLE) is a forecast of how long it should take a single work item to flow from started to finished.
      • The SLE itself has two parts: a period of elapsed time and a probability associated with that period (e.g., “85% of work items will be finished in eight days or less”).
      • The SLE should be based on historical cycle time, and once calculated, should be visualized on the Kanban Board.
        • If historical cycle time data does not exist, a best guess will do until there is enough historical data for a proper SLE calculation.
    • Scrum and Kanban

    Sharing of Knowledge

    • Ideally, Agile teams are best to be co-located (working within the same room with seats facing each other) to enhance pro-active support, free discussion, open collaboration and osmotic communication
      • Face-to-face communication is always encouraged
      • Practice pair programming if feasible
      • Make use of daily stand-up, review and retrospectives
      • Make use of Agile tooling to enhance sharing of knowledge:
      • Since documentations are not encouraged, co-located teams can share tacit knowledge more readily

    Shopping List

    • Shopping List is nothing except a list of features that the Product Owner wants, with no unifying principle or clear goal.
      • This does nothing to guide the team (or inspire the team).
      • It also rarely passes the elevator test and usually is also difficult to remember.
      • What it adds up to is that it does nothing to align the team or help them make decisions, and as a result the “secret sauce” in Scrum (Self-organization) never emerges or emerges misdirected.

    Shu-Ha-Ri model (by Alistar Cockburn)

    • It is recommended to follow the Shu-Ha-Ri model (by Alistar Cockburn) if you would like to make changes
      • Shu-Ha-Ri originates from masters of Japanese Noh theater
      • SHu-Ha-Ri :
        • Shu
          • Obeying the rules
        • Ha
          • Consciously moving away from the rules
        • Ri
          • Unconsciously finding an individual path

    Single Responsibility Principle

    • S – Single-Responsibility Principle – This principle states that an object/class should only have one responsibility and that it should be completely encapsulated by the class.
      • The Single Responsibility Principle says to separate the code that different actors depend on.
        • Also, gather together the things that change for the same reasons.
        • Separate those things that change for different reasons.
        • To sum up, a class should have one and only one reason to change, meaning that a class should have only one job.
        • See Scrum and Coding Principles

    Site Map

    • A site map provides a hierarchical organization of the pages that comprise a website.

    Sit together

    Sketch

    • Sketch, Wireframe, Mockup and Prototypes actually represent the different stages of the design flow.
    • The Sketch is the simplest way to present an idea or initiative, even can be drawn in a piece of paper and has a minimum level of fidelity.

    Sketch, Wireframe, Mockup and Prototype

    • In order to prevent creating the wrong product or having reworks, it is valuable using some approach to make a better understanding of customer requirements :
    • Sketch, Wireframe, Mockup and Prototype actually represent the different stages of the design flow :
      • They start from low-fidelity and end with high-fidelity respectively.
        • Sketch
          • The sketch is the simplest way to present an idea or initiative, even can be drawn in a piece of paper and has a minimum level of fidelity.
        • Wireframe
          • Wireframe, a low-fidelity way to present a product, can efficiently outline structures and layouts.
        • Mock-up
          • A mockup looks more like a finished product or prototype, but it is not interactive and not clickable.
        • Prototype
          • However, a prototype has a maximum level of fidelity and is interactive and clickable.

    Slack

    • eXtreme Programming (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.

    SLE (Service Level Expectation)

    • The Service Level Expectation (SLE) is a forecast of how long it should take a single work item to flow from started to finished.
      • The SLE itself has two parts: a period of elapsed time and a probability associated with that period (e.g., “85% of work items will be finished in eight days or less”).
      • The SLE should be based on historical cycle time, and once calculated, should be visualized on the Kanban Board.
        • If historical cycle time data does not exist, a best guess will do until there is enough historical data for a proper SLE calculation.
    • Scrum and Kanban

    SLOC reports (Source line of code reports)

    • Source Lines of Code (SLOC) reports are an imperfect source to be used for productivity reports. [The Art of Agile Development. James Shore.]

    SMART

    • S
      • Specific tasks are ones that clearly contribute to the development of a User Story
        It should not be vague.
    • M
      • Measurable tasks are ones that the team and customer can verify.
    • A
      • Achievable tasks are ones that developers may realistically implement and understand.
    • R
      • Relevant tasks are ones that unequivocally add value to the User Story.
    • T
      • Timeboxed tasks are ones that can have an estimate assigned of the amount of effort or time needed for development.
    • [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

    Smells

    • Agile term for “symptoms of a problem”, they are signs that the Agile project is not running properly and problems are in the making

    Smoke Testing

    • Smoke Testing is a non-exhaustive set of tests that aim at ensuring that the most important functions work.
      • Smoke Testing, or “Build Verification Testing”, is a type of software testing that includes a non-exhaustive set of tests that aim at ensuring that the most crucial and important functions work.
      • The result of this testing is used to decide if a build is stable enough to proceed with further testing.
    • Smoke Testing is the preliminary check of the software after a build and before a release.
      • This type of testing finds basic and critical issues in an application before critical testing is implemented.

    Social media-based communication

    • social media are a great way to collect ideas, requirements and feedback from the community :
      • convenient
      • instantly
      • two-way communication

    Soft skills negotiation

    • Key soft skills negotiation qualities for the effective implementation and practice of agile are: emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution, servant leadership. [Coaching Agile Teams. Lyssa Adkins.]
    • 6 keys :
      • Emotional intelligence
      • Collaboration
      • Adaptive leadership
      • Negotiation
      • Conflict resolution
      • Servant leadership

    Software Process Improvement (SPI)

    • Software Process Improvement.

    SOLID Principle

    • SOLID is Object Oriented Design
    • S.O.L.I.D. is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin, popularly known as Uncle Bob.
      • These principles, when combined together, make it easy for a programmer to develop software that is easy to test, maintain, and extend.
      • They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development.
      • It includes the following principles: Single responsibility principle, Open-closed principle, Liskov substitution principle, Interface segregation principle, and Dependency inversion principle.
    • SOLID principles help software developers to achieve scalability and avoid that your code breaks every time you face a change.
    • See Scrum and Coding Principles

    Source line of code reports (SLOC)

    • Source Lines of Code (SLOC) reports are an imperfect source to be used for productivity reports. [The Art of Agile Development. James Shore.]

    Spike

    • Spike is a short experimental test to help decisions making, e.g. trying a new technology for feasibility study
    • Spike is a short focused period of development undertaken to prove new technology.
      • For example “We’ll spike the Oracle 10g compatibility”
    • “A Spike is an investment to make the User Story estimable or schedule-able.”
    • A Spike is a product development method originating from eXtreme Programming (XP) that uses the simplest possible program to explore potential solutions.
    • A Spike is a story or task aimed at answering a question or gathering information, rather than at producing shippable product.
    • A Spike is an experiment which enables developers to estimate the User Story by giving them enough information about the unknown elements of the same story.
    • See also :

    Spike Testing

    • Typically, a “Spike Test” involves gathering additional information or testing for easily reproduced edge cases.

    Sprint

    • Sprint is an iteration, a period of time to undertake development.
      • In the Scrum framework the Sprints are typically 15 to 30 days in duration.
        • Sprint is a Scrum Event that is time-boxed to one month or less, that serves as a container for the other Scrum Events and activities.
      • Sprints are done consecutively, without intermediate gaps.
    • Sprint is an event of the Scrum framework like an Iteration and a container for Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.
      • A Sprint is a time-boxed amount of work that the team sets out to complete.
        • Ideally, all of the work within this period of time will be 100% completed and the resulting work will be ready to ship at the end of the period.
        • Most iterations run about one week to one month in length.
      • The Sprint begins with Sprint Planning and ends with a Sprint Retrospective.

    Sprint Backlog

    • The Sprint Backlog is a list of the product features to be developed in a Sprint.
      • The Sprint Backlog is a list of product features or work items to be completed in a Sprint.
        • Sprint Backlog is a Scrum Artifact that provides an overview of the development work to realize a Sprint’s goal, typically a forecast of functionality and the work needed to deliver that functionality.
        • Managed by the Developers.
      • It is typically fixed for the Sprint unless it is overcome by important customer requirements.
      • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
    • The Sprint Backlog lists all of the tasks to be completed in order to complete all of the stories assigned to the Sprint.

    Sprint Goal

    • Sprint Goal is a short expression of the purpose of a Sprint, often a business problem that is addressed.
      • Functionality might be adjusted during the Sprint in order to achieve the Sprint Goal.
    • A good sprint goal provides the same guiding effect that we observe from a good product vision.
      • It provides context for the Developers, allowing them to make good decisions when executing on their commitment.
      • It also helps the Product Owner focus by providing a need for the Product Owner to have a strong theme or goal.
        • Merely re-stating the stories committed to in Sprint Planning will not be sufficient to provide this focus.
        • It requires a grasp of the business value and the ability to communicate this as a coherent goal on the tactical level of the Sprint.
      • An inability to articulate a sprint goal is usually symptomatic of poor product vision.
        • This is “feature soup” and at the sprint level: “story soup”.
      • A good sprint goal also provides the team with some “wiggle room” in terms of meeting their commitment.
        • If the team runs into trouble during the sprint, examine their ability to deliver in light of the sprint goal to see if there is room to de-scope items without affecting the goal.
      • Finally, the sprint goal is also used as an acid-test of whether a Sprint should be terminated.
        • Termination is a drastic and hopefully infrequent event in most Scrum Team’s lives.
        • If however the environment or assumptions for choosing the sprint goal no longer match the reality, this could be cause for the Product Owner to choose to terminate.

    Sprint Planning

    Sprint Retrospective

    Sprint Review

    • Sprint Review is a mandatory Event of the Scrum and is about the Product.
      • Sprint Review is a meeting for presenting the Increment for feedback and collaboration.
      • A time-boxed of 4 hours, or less, to conclude the development work of a Sprint.
        • It serves for the Scrum Team and the stakeholders to inspect the Increment of product resulting from the Sprint, assess the impact of the work performed on overall progress toward the Product Goal and update the Product Backlog in order to maximize the value of the next period.
      • The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

    Stakeholders

    • a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery.
    • Stakeholders are a critical component of the agile framework where the latest increment of product functionality is demonstrated to the stakeholders for inspection, feedback, and adapting. [Agile Estimating and Planning. Mike Cohn.]
      • Stakeholders : anyone who have an impact on /will be impacted by the project (e.g. sponsor, vendors, final customers, community, etc.)
      • The project team is considered stakeholders in traditional project management (according to PMBOK® Guide) but not in Agile projects

    Stakeholder communication

    • It is critical for the project team to communicate frequently with the stakeholders to ensure everyone is on the some page and kept up to date.
      • In addition project failures can often traced back to communication failures.

    Stakeholder engagement

    • Keep stakeholders engaged so we will here about change requests asap.
      • Agile methods provide multiple touchpoints to dialogue about scope, risks & changes (scrum)
      • Not all stakeholders can be handled in the same way.
        • The facilitator (Scrum Master) needs to map the opportunities & constraints by identified groups of stakeholders

    Stakeholder management

    • Stakeholder : anyone who have an impact on /will be impacted by the project (e.g. sponsor, vendors, final customers, community, etc.)
      • the project team is considered stakeholders in traditional project management (according to PMBOK® Guide) but not in Agile projects
    • Stakeholder management processes :
      • identify all the stakeholders periodically (in particular the key stakeholders who will have a big impact on project success)
      • communicate with selected stakeholders for requirements and needs gathering
      • enhance stakeholder involvement by active communication and information sharing the type and level of details of the information should be appropriate for the type of stakeholders
      • show project progress (just detailed enough) with demos / presentations as project evolves, the interests of key stakeholders must be managed actively
      • discuss updated estimates and projections timely and openly (even in case of bad news) so as to facilitate future planning
      • keep a good relationship with all stakeholders by disseminating necessary information and collecting feedback from them
        • may need to educate stakeholders about the processes and benefits of Agile project management to solicit their support
        • stakeholders may be invited to Review and planning meetings in order to update them about the project progresses

    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.]
    • Scrum Developers work toward company, development and organizational Standards.
    • Common Standards used during coding
      • Pointer and Reference Usage
      • File Naming Convention
      • Naming Convention (the benefit of establishing naming Standards for code is that it makes the code more Readable)
      • Formatting and Indentation
      • Classes, Functions and Interfaces
      • Comments and Documents
    • See Version Control, branching and Merging and Standards

    Standup meeting

    • These regular meetings are used as a quick way to update all of the team on each member’s individual progress.
      • They’re often held on a daily basis and cover current activity, any pending items, roadblocks, or questions.
    • 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.

    Stand-up meeting and Daily Stand-up meetings

    • A Stand-up meeting is typically held daily and is often referred to as the Daily stand-up meeting. [The Art of Agile Development. James Shore.]
      • The term « stand-up » originates from the fact that ALL team members are encouraged to stand during the meeting to promote meeting efficiency.
      • The theory is that by physically standing no one will get comfortable enough to waste valuable time.
      • [The Art of Agile Development. James Shore.]
    • In the scrum-based agile project management methodology, daily stand-up meetings are referred to as ‘scrums’ or ‘Daily scrum.’ [The Art of Agile Development. James Shore.]
    • In the Scrum framework, daily stand-up meetings, or daily scrums, should last no longer than 15 minutes.
      • Some scrum instances use stop watches to track time and use a ‘talking stick’ to help indicate whose sole turn it is to share pertinent information. [The Art of Agile Development. James Shore.]
    • In a Daily Stand-up meeting team members discuss current progress and any issues or impediments that are impacting progress.
      • Each team member shares what he or she has achieved since the last meeting, what he or she will achieve before the next meeting, and what obstacles may prevent him or her from achieving progress. [The Art of Agile Development. James Shore.]
    • The key characteristics of a healthy stand-up meeting include :
      • peer pressure
        • the team is dependent upon each other so expectations of peers drives progress;
      • fine-grained coordination
        • the team should understand the necessity for focus and working dependently;
      • fine focus
        • the team should understand the need for brevity in the stand-up meeting so the team can be productive;
      • daily commitment
        • the team should understand the value of daily commitments to each other and uphold those commitments;
      • identification of obstacles
        • the team collectively should be aware of each other’s obstacles so that the team collectively can try to resolve them.
      • [The Art of Agile Development. James Shore.]
    • Fine-grained coordination, a fine focus, and daily commitment :
      • Issues that take longer than a few minutes to resolve in a Daily Stand-up meeting should be tabled and resolved between the appropriate parties after the Daily Stand-up meeting has concluded.
      • This ensures that the meetings are brief and productive.
      • [The Art of Agile Development. James Shore.]
    • The use of a stop watch is sometimes used in the Daily Stand-up meeting to ensure that the meeting is brief and productive. Typically, a stand-up meeting should last no longer than 15 minutes (i.e., a 15 minute timebox). [The Art of Agile Development. James Shore.]
    • A high-performance, self-organizing team should realize and correct the disruptive behavior. [Coaching Agile Teams. Lyssa Adkins.]

    Static Analysis

    • Static Analysis, also called static code analysis, is a method of computer program debugging that is done by examining the code without executing the program.
      • Static code analysis is a method of debugging by examining source code before a program is run.
      • It’s done by analyzing a set of code against a set (or multiple sets) of coding rules.

    Stories

    • Stories are small, independent units of work that are derived from use cases or technical specifications.

    Story mapping

    • A story map organises User Stories according to a narrative flow that presents the big picture of the product.
      • The technique was developed by Jeff Patton from 2005 to 2014 to address the risk of projects flooded with very detailed user stories that distract from realizing the product’s main objectives.[citation needed]
    • User story mapping uses workshops with users to identify first the main business activities.
      • Each of these main activities may involve several kind of users or personas.
    • The horizontal cross-cutting narrative line is then drawn by identifying the main tasks of the individual user involved in these business activities.
      • The horizontal axis corresponds to the coverage of the product objectives.
      • The line is kept throughout the project.
      • More detailed user stories are gathered and collected as usual with the user story practice.
      • But each new user story is either inserted into the narrative flow or related vertically to a main tasks.
    • The vertical axis corresponds to the needs of the individual users.
    • In this way it becomes possible to describe even large systems without losing the big picture.
    • Story maps can easily provide a two-dimensional graphical visualization of the Product Backlog:
      • At the top of the map are the headings under which stories are grouped, usually referred to as ‘epics’ (big coarse-grained user stories), ‘themes’ (collections of related user stories) or ‘activities’.
      • These are identified by orienting at the user’s workflow or “the order you’d explain the behavior of the system”.
      • Vertically, below the epics, the actual story cards are allocated and ordered by priority.
      • The first horizontal row is a “walking skeleton” and below that represents increasing sophistication.

    Story maps

    • Story Maps are overview of how different User Stories are related to each other in the project :
      • Story Map help select and group features for release.
      • It shows the sequence and indicates their importance by classifying them as backbone (walking skeleton)
        • The walking skeleton describes the minimal features to have a working outcome
        • Once the features are placed on the map according to their importance and sequence they are balanced with the teams capacity to deliver, 1st release, 2nd release, …
    • In agile, the story map is essentially the project plan.
      • It orders the User Stories/product features into logical themes to serve as a plan for development.
      • [User Stories Applied: For Agile Software Development. Mike Cohn.]

    Story points

    • Story points are used in agile methodologies to help calculate how many User Stories a team can take in an iteration.
    • Story points is a fixed and relative value of development effort.
      • Story points represent the relative work effort it takes to develop a User Story.
        • Agile teams typically use story points to estimate the relative size or effort of developing a User Story [Agile Estimating and Planning. Mike Cohn.]
      • Each point represents a fixed value of development effort.
      • It is used in the relative sizing of User Stories to estimate work effort involved with development.
      • Story points are not time-based.
      • When estimating the agile team must consider complexity, effort, risk, and inter-dependencies.
      • [Agile Estimating and Planning. Mike Cohn.]
    • We give a relative score to the grade of difficulty & time of each work (Story Points/Item) and compile those story points per iteration.
      • The idea is to get away from estimating in hours to give more tolerance & be more adaptive as new information becomes available.
      • Teams should own the Story points
      • Story Points estimates should be all inclusive, complexity, effort & risk
      • When disagreeing, the totals do not need to match
      • Size should be relative

    Story points / Relative sizing

    • Agile project management makes use of relative sizing (e.g. story points) as opposed to the use of exact units like money and time in traditional project management for estimation as Agile projects are more prone to changes, making use of relative sizing will be more flexible yet still give a reference for meaningful estimation
      • Agile teams typically use story points to estimate the relative size or effort of developing a User Story [Agile Estimating and Planning. Mike Cohn.]
    • Agile teams should agree to one method of estimation, either story points or ideal days, as both use different units of measurement and can lead to confusion. [Agile Estimating and Planning. Mike Cohn.]
    • Instead of using story points, agile teams may estimate the relative sizes of user stories using ideal days.
      • Ideal days represents the amount of days – uninterrupted by meetings, personal life, non-working days, or any other delays, obstacles or distractions – that it would take a single person to build, test, and release the User Story, relative to other User Stories in the Product Backlog. [Agile Estimating and Planning. Mike Cohn.]
    • Both Planning poker and affinity estimation are agile techniques used to size the work effort of developing User Stories. [Agile Estimating and Planning. Mike Cohn.]

    Strategy Agility

    • Strategy Agility is :
      • Respond quickly to opportunities and threats
      • Implement changes in strategy

    Strategic Debt

    Structural design patterns

    • In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships among entities.
    • See Scrum and Software Development Practices

    Sunny Day Testing

    • Happy Pass testing (Sunny Day Testing) is a type of software testing that uses known input and produces an expected output.
      • Also referred to as golden-path or sunny-day testing, the happy-path approach is tightly scripted.
      • The happy path does not duplicate real-world conditions and verifies only that the required functionality is in place and functions correctly.
      • If valid alternatives exist, the happy path is then identified as the default scenario or the most likely positive alternative featuring no exceptional or error conditions.
    • In the context of software or information modeling, a happy path (sometimes called happy flow) is a default scenario featuring no exceptional or error conditions.
      • For example, the happy path for a function validating credit card numbers would be where none of the validation rules raise an error, thus letting execution continue successfully to the end, generating a positive response.
    • Process steps for a happy path are also used in the context of a use case.
      • In contrast to the happy path, process steps for alternate paths and exception paths may also be documented.
    • Happy path test is a well-defined test case using known input, which executes without exception and produces an expected output.
      • Happy path testing can show that a system meets its functional requirements but it doesn’t guarantee a graceful handling of error conditions or aid in finding hidden bugs.
    • In use case analysis, there is only one happy path, but there may be any number of additional alternate path scenarios which are all valid optional outcomes.
      • If valid alternatives exist, the happy path is then identified as the default or most likely positive alternative.
      • The analysis may also show one or more exception paths.
      • An exception path is taken as the result of a fault condition.
      • Use cases and the resulting interactions are commonly modeled in graphical languages such as the Unified Modeling Language or SysML.
    • See Scrum and Coding Principles

    System Requirements

    • System requirements may reflect user requirements that are not tied to a single use case or non-functional requirements that relate to the technical architecture.

    Tabaka’s model for high-performing team

    • self-organization
    • empowered to make decision
    • belief in vision and success
    • committed team
    • trust each other
    • participatory decision making
    • consensus-driven
    • construction disagreement

    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.]

    Tactical debt

    Tasks

    • The acronym SMART (specific, measurable, achievable, relevant, and time-boxed) helps the agile practitioner remember the characteristics of a well-defined Task.

    Tasks

    • the underlying jobs / development work to fulfill a user story, tasks are taken up by the team members through self-organization
    • Tasks must be SMART :
      • S
        • Specific tasks are ones that clearly contribute to the development of a User Story
          • It should not be vague.
      • M
        • Measurable tasks are ones that the team and customer can verify.
      • A
        • Achievable tasks are ones that developers may realistically implement and understand.
      • R
        • Relevant tasks are ones that unequivocally add value to the User Story.
      • T
        • Timeboxed tasks are ones that can have an estimate assigned of the amount of effort or time needed for development.
      • [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
    • Agile team members should feel free to update incorrect task time estimates as soon as possible.
      • Team members can use current iteration progress and accrued experience to come to a new task time estimate.
      • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
    • More at Tasks board and Kanban Board

    Tasks Board

    • an agile team often uses a Tasks board to monitor and control progress.
      • A Tasks board identifies tasks to be completed during an iteration and their progress. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
      • More at Tasks board and Kanban Board

    Technical Specifications

    • The Technical Specifications document documents the technical architecture approaches and designs involved in the project such as applications, databases, systems integration mechanisms, data migration requirements, infrastructure requirements and programming tools and practices.
      • The technical specifications document contains technical architecture and design details.

    Team Collaboration and Commitment

    • Align the goals of the project and the team members with a shared project vision.
      • Shield the team from external distraction and pressure to ensure performance.
      • Make use of collaboration tools and colocation to enhance communication within the team and between team and stakeholders.
      • Measure the team velocity by tracking work performance in previous iterations to allow more accurate forecasts.

    Team Empowerment

    • Create a high performing team in which members can perform as generalizing specialists carrying out cross-functional tasks.
      • Empower team members to make decisions and to lead in order to create a self-organizing team.
      • Understand motivators and demotivators of the team and individuals to ensure high team morale.
    • Team Empowerment :
      • Fixed Time Box
      • Requirements at a High Level
      • Incremental Project Releases
      • Frequent Delivery
      • Finish Tasks One by One
      • Pareto Principle
      • Testing – Early and Frequent
      • Teamwork

    Team Formation

    • Form the team with members who possess all the necessary skills (interpersonal and technical) to deliver the intended outcomes and values of the project.
      • The team works together to establish ground rules and processes to strengthen sense of belonging and create a shared goal of the team members.

    Team Formation Stages

    • Tuckman model (Tuckman’s stages of group development)
      • Forming
        • the group is formed, everyone behaves independently
      • Storming
        • disagreements arise between team members
      • Norming
        • team members accept each other by emphasising the group goal
      • Performing
        • the team is highly motivated and efficient
      • Adjourning
        • tasks completed
    • At stage 4, the group is considered to be most efficient and best performing, it’s a Team.
      • However, not every group goes through every stage of the Tuckman model, some may stay at stage 2 and others can jump to stage 5 without going through stages 3 and 4.

    Team Participation

    • The whole project team would discuss in details about the requirements of customers through face-to-face communication:
      • Brainstorming
        • everyone can voice out their opinions freely without immediate judgement
      • Innovation games
        • games are used to engage the team members and customer, e.g. 20/20 Vision, the Apprentice, Buy a Feature, Product Box, Prune the Product Tree (reference: Innovation Games: Creating Breakthrough Products Through Collaborative Play by Luke Hohmann).
      • Parking lot chart
        • a piece of paper to put important but off-topic issues / queries for later investigation / discussion, e.g. in requirement gathering

    Team space

    • A high-performance, Self-Organizing team should realize and correct the disruptive behavior. [Coaching Agile Teams. Lyssa Adkins.]
      • prefer all team members to be collocated in the same room facing each other for pro-active support, free discussion, open collaboration, tacit knowledge sharing and osmotic communication. If physical co-location is impossible, can make use of virtual co-location tools (e.g. instant messaging, video conferencing, etc.)

    Technical debt

    • Technical Debt is the amount of Escaping defects at a time.
      • 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 eXtreme Programming (XP).
      • Technical Debt is the typically unpredictable overhead of maintaining the product, often caused by less than ideal design decisions, contributing to the total cost of ownership.
      • A Technical debt represents results which are a consequence of poor technical choices.
    • See :

    Technical debt types

    • Technical debt types are as following :
      • Implementation debt :
        • Bad coding
      • Architecture debt :
        • Bad architectural principles, design rule violations, lacking design patterns
      • Test debt:
        • Missing test cases, lack of test coverage, lack of test automation
      • Documentation debt :
        • Missing documentation, poorly updated documentation, low traceability between documentation and implementation
    • See :

    Technical Spike definition

    Ten-minutes Build Principle

    Test Double

    • Test Double is a generic term for any case where you replace a production object for testing purposes.
      • There are at least five types of Test Doubles :
        • Test Stub,
        • Mock Object,
        • Test Spy,
        • Fake Object, and
        • Dummy Object with some differences.
      • See Mocks, fakes, and stubs
    • Test Double is used to resolve dependencies.

    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.
    • Test Driven Development (TDD) is an agile methodology that has software developers develop automated software tests before developing software that implements product features.
      • This helps ensure quality as each bit of feature software is tested individually to remove bugs and improve performance before it is integrated with the final product. [The Art of Agile Development. James Shore.]
    • The Test Driven Development (TDD) process has four basic steps :
      • 1) Write a test,
      • 2) Verify and validate the test,
      • 3) Write product code and apply the test,
      • 4) Refactor the product code.
    • An example may be that a user has to enter an age value.
      • A good test is to make sure the user data entry is a positive number and not a different type of input, like a letter (i.e., write the test).
      • The programmer would verify that entering a letter instead of a number would cause the program to cause an exception (i.e., v&v the test).
      • The programmer would then write product code that takes user entry for the age value (i.e., write the product code).
      • The programmer would then run the product code and enter correct age values and incorrect age values (i.e., apply the test).
      • If the product code is successful, the programmer would refactor the product code to improve its design.
      • Using these four steps iteratively ensures that programmers think about how a software program might fail first and to build product code that is holistically being tested.
      • This helps produce high quality code.
      • [The Art of Agile Development. James Shore.]
    • 4 steps in Test Driven Development (TDD) = WVWR
      • 1) Write a test
      • 2) Verify and validate the test
      • 3) Write product code and apply the test
      • 4) Refactor the product code
    • By doing Test Driven Development (TDD) we control Scope creep.
      • By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding.

    Test first Development (TFD)

    • Test First Development (TFD) is designing tests before satisfying them.
    • Test First Development (TFD) is an approach to development in which Developers do not write a single line of code until they have created the test cases needed to prove that unit of work solves the business problem and is technically correct at a unit-test level.
      • In a response to a question on Quora, Beck described reading about developers using a test-first approach well before XP and Agile.
      • Test First Development (TFD) is test-first development combined with design and code refactoring.
      • Both test-first and test-driven development are useful for improving quality, morale and trust and even though both are related they not the same.
    • Test First Development (TFD) is an evolutionary approach to programming where agile software Developers must first write a test that fails before they write new functional code.
    • Test First Development (TFD), also known as Test Driven Development (TDD) is a development style in which you write the Unit Tests before you write the code to test.

    Testing

    • In lean agile the Testing is done to improve the process and quality.
      • The Testing activity should discover the causes of errors and eliminate them.
      • Root-cause analysis is part of the Testing’s portfolio of work.
      • In lean we work with a principle-build quality so that the process should ensure we develop quality products, Testing alone cannot ensure that we deliver good quality products to the user.

    Theme

    • A theme, in the context of agile development, is a set of related user stories. [User Stories Applied: For Agile Software Development. Mike Cohn.]
      • a theme is usually assigned for an iteration in which similar functions are grouped to be done in a batch to maintain focus of the team, e.g. bug fix, reporting, etc.

    Throughput

    • The number of work items finished per unit of time.
      • Note the measurement of throughput is the exact count of work items.
      • Scrum and Kanban

    Throughput and Cycle Time

    • Cycle time is the time necessary to get a single item of work done from start (idea) to finish (as a shippable product that delivers value)
      • Cycle time can be reduced by shortening iteration time (breaking down task sizes), limiting Work In Progress and reducing wastes
    • Throughput is the number of things that can be done in an iteration
    • Cycle Time = WIP / Throughput
      • Defect cycle time is the time between defect injection and defect remediation, the shorter the defect cycle time the better
    • Scrum and Kanban

    Timebox

    • A timebox refers to a previously agreed period of time during which a person or a team works steadily towards completion of some goal.

    Time boxing

    • time-boxing is a concept for time management by treating time as fixed blocks
      • once the allotted time (time-box) is up, the work must be stopped regardless of whether it has been finished
      • with fixed start time, fixed end time and fixed duration for the activity to control the risk and progress
      • time-boxing allows the team to focus on the essential works and reduce wastes
    • Timeboxing is a realistic estimate or expectation of how long an action, task, or event will take to perform.
      • Some tasks cannot be performed in the initial timeboxed estimate and are good candidates for reevaluation and possibly further decomposition into more tasks. [The Art of Agile Development. James Shore.]
    • Avantages of Timeboxing :
      • Establishes a WIP Limit
      • Forces Prioritization
      • Demonstrates Progress
    • Timeboxing in Scrum

    Time, budget, and cost estimation

    • Time, budget, and cost estimation is an important knowledge and skill area of agile.
      • Fixed-budget and fixed-schedule is a good agile contract
        • According to Highsmith, the nature of the agile method, whereby it welcomes changing scope, means that it lends itself well to fixed budgets and a fixed schedule because changing scope makes it difficult to estimate a total cost.
      • Generally speaking, the budget and schedule constraints are known but before a project will commence there needs to be an agreed upon set of base product functionality defined in an initiation phase; fixing scope reduces an agile team’s innovative tendency to provide improved value.

    Traditional Functional Testing :

    • Traditionally, not in Agile testing, functional testing is implemented by a team of testers, independent of the developers.
    • However Functional tests can be automated.
    • See Testing

    Traditional plan to Agile Baseline

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

    Traditional Project

    • In a traditional Project, plan what you expect to happen :
      • Enforce that what happens is the same as what is planned
    • Directive management
      • Control, control, control
    • Change Control Board
      • Use change control to manage change
    • Defect Management

    Traditional project management

    • Plan what you expect to happen
    • Enforce that what happens is the same as what is planned
    • Directive management
    • Control, control, control
    • Use change control to manage change
    • Change Control Board
    • Defect Management

    T-shirt Sizing

    • assign a size (e.g. T-shirt sizing: S, M, L, XL, XXL) to User Stories instead of giving a more concrete unit, this method is ideal if the scope / details of the task are not quite concrete

    Tuckman’s Stages of Team Development

    • Team Formation Stages
      • Forming
        • the group is formed, everyone behaves independently
      • Storming
        • disagreements arise between team members
      • Norming
        • team members accept each other by emphasising the group goal
      • Performing
        • the team is highly motivated and efficient
      • Adjourning
        • tasks completed
    • At stage 4, the group is considered to be most efficient and best performing, it’s a Team.
      • However, not every group goes through every stage of the Tuckman model, some may stay at stage 2 and others can jump to stage 5 without going through stages 3 and 4.
    • See Tuckman’s Stages of Team Development

    Two-way Communication

    • Agile project management emphases feedback as feedback can help reducing mis-understanding and risks and generate better ideas.
      • Communication must always be two-way, all the parties are given the opportunity to voice out their concerns and points of views

    Unhappy Pass Testing

    • Sad Pass Testing (Unhappy Pass, Rainy Day)
    • There is no agreed name for the opposite of happy paths : they may be known as sad paths, bad paths, or exception paths.
      • The term ‘unhappy path’ is gaining popularity as it suggests a complete opposite to ‘happy path’ and retains the same context.
      • Usually there is no extra ‘unhappy path’, leaving such ‘term’ meaningless, because the happy path reaches the utter end, but an ‘unhappy path’ is shorter, ends prematurely, and doesn’t reach the desired end, i.e. not even the last page of a wizard.
      • And in contrast to a single happy path, there are a lot of different ways in which things can go wrong, so there is no single criterion to determine ‘the unhappy path’.
    • See Scrum and Coding Principles

    Unit Test Scripts

    • Unit test scripts are written by the developer to test the smallest units of code.
      • Sometimes, they are organized into a hierarchical test harness that can effectively regression test an entire system if implemented properly.

    Unit Testing (UT)

    • Unit Testing (UT) is a Practice of testing certain functions and areas of code or individual units of source code.
      • Unit Test is a test that isolates and verifies individual units of source code.
    • A Unit Test is a way of testing a unit (the smallest piece of code) that can be logically isolated in a system.
      • In most programming languages, that is a function, a subroutine, a method or property.
      • A Unit Test can be automated.

    Usability testing

    • Usability Testing is a special type of Exploratory Testing with emphasis on the usability of the software interface (whether the test subject will be able to perform core tasks on the interface without instructions and help)
      • help to provide insights on the design of the software :
        • Users’ expectations / habits
        • Users’ ability to understand / comprehend the design of the interface
        • Users’ value of the functions of the software
    • Exploratory Testing and Usability testing both will provide valuable feedback early in the project to enhance value delivery and avoid failure later on

    Use Case Register

    • The use case register lists all use cases and key information about them.

    User Acceptance Testing (UAT)

    User Analysis

    • User analysis includes a description of each category of user that will interact with the system.
      • Sometimes, user analysis takes the form of a set of personas for each of the types of users.
      • Doing so helps team members identify actors and to visualize each type of user in a meaningful way during design and development activities.

    User 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 eXtreme Programming (XP).
      • Some agile methods use Features, or Prioritized requirements as their requirement units.
    • A User Story is composed of the following three aspects :
      • 1) A written description of the story;
      • 2) Conversations about the story (think verbal, rather than written here); and,
      • 3) Tests that convey when a story can be accepted or complete. [User Stories Applied: For Agile Software Development. Mike Cohn.]
    • User Stories include activities that have a clear end point or exit criteria. [User Stories Applied: For Agile Software Development. Mike Cohn.]
    • The ideal development duration range for a User Story is 2 to 5 days. [User Stories Applied: For Agile Software Development. Mike Cohn.]
    • These stories are created as a way for product owners to communicate specific functionality to the team.
      • It’s meant to be couched from the perspective of the user and describe a specific action that they will take and/or outcome that should be developed.
      • A typical user story template may look something like this:
      • As a < type of user >, I want < some goal > so that < some reason >.
      • The purpose of the user story is to dissect larger features or functionality into discrete increments that can be implemented in a relatively small window of time and then improved or expanded in future iterations.

    User Story 3 C

    User Story impediment

    • When an agile team is scoring a particularly vague and unclear User Story, it typically assigns it a high value knowing that it will most likely become further defined in upcoming iterations. [Agile Estimating and Planning. Mike Cohn.]

    User Story INVEST

    • INVEST : Independent, negotiable, valuable, estimable, small, and testable
      • The acronym INVEST (independent, negotiable, valuable, estimable, small, and testable) helps the agile practitioner remember the characteristics of a good User Story.
      • I – Independent stories can be developed in any order and avoid dependencies which can make development more complex. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
      • N – Negotiable User Stories mean that both the customer and Developers should feel free to analyze and adapt a user story to meet customer needs. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
      • V – A valuable User Story describes how the product feature will provide value to the customer. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
      • E – Estimable User Stories are ones that Developers can readily estimate the effort or duration required for developing them. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
      • S- Small User Stories are ones that take about two to five days of work to implement. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
      • T – Testable User Stories are ones that can be verified according to acceptance criteria to ensure value. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]
      • See eXtreme Programming (XP) and Planning poker

    User stories or features

    • User Stories or features are first assigned to iterations during release planning.
      • The User Stories are features are then decomposed into tasks during iteration planning so that the tasks may be assigned to specific developers.
        • To help manage planning and monitoring, a rule of thumb for estimating task duration is that each task should take approximately four hours to two days of development work.
        • The Art of Agile Development. James Shore.]
        • More at User Stories
    • User Stories usually takes the format of “As a [role], I want [need] so that [business value]”
      • to describe the requirements in real world scenarios
      • often written on Story Cards
      • User stories need to be Independent, Negotiable (can be discussed on implementation), Valuable, Estimatable (with adequate info for meaningful estimation), Small, Testable [INVEST]
      • [Ron Jeffries’ three Cs of user story] Card, Conversation, Confirmation
    • User Stories are prioritized based on customer value.
      • Value is determined by return on investment, growth of team knowledge, and risk reduction.
      • [The Art of Agile Development. James Shore.]
    • The team should meet with the customer to determine if and when the User Story should be completed. [Agile Estimating and Planning. Mike Cohn.]
    • A User Story is composed of the following three aspects :
      • 1) A written description of the story;
      • 2) Conversations about the story (think verbal, rather than written here); and,
      • 3) Tests that convey when a story can be accepted or complete. [User Stories Applied: For Agile Software Development. Mike Cohn.]
    • User Stories include activities that have a clear end point or exit criteria. [User Stories Applied: For Agile Software Development. Mike Cohn.]
    • The ideal development duration range for a User Story is 2 to 5 days. [User Stories Applied: For Agile Software Development. Mike Cohn.]
    • See eXtreme Programming (XP) and Planning poker

    User Story priorization

    • User Stories are prioritized based on customer value.
      • Value is determined by return on investment, growth of team knowledge, and risk reduction. [The Art of Agile Development. James Shore.]
      • The team should meet with the customer to determine if and when the User Story should be completed. [Agile Estimating and Planning. Mike Cohn.]
    • User Stories may be prioritized with Planning poker.
    • See eXtreme Programming (XP) and Planning poker

    User Story Reference point

    User Stories story points

    • In general, story points can be considered as the cost of developing a User Story, while value points can be considered as the benefit of developing a User Story. [Agile Estimating and Planning. Mike Cohn.]
      • A 0 point User Story is said to be of minimal effort for a development team. [Agile Estimating and Planning. Mike Cohn.]
    • See eXtreme Programming (XP) and Planning poker

    User story time-boxed value

    • Two to three minutes is a typical time-boxed value for discussing User Stories when playing Planning poker. [Agile Estimating and Planning. Mike Cohn.]
    • Triangulation
      • Triangulation involves estimating the relative effort of developing a User Story by comparing it against two other User Stories [Agile Estimating and Planning. Mike Cohn.]
    • Vague and unclear User Story
      • When an agile team is scoring a particularly vague and unclear User Story, it typically assigns it a high value knowing that it will most likely become further defined in upcoming iterations. [Agile Estimating and Planning. Mike Cohn.]
      • Assign the User Story an arbitrarily high number.
    • Tasks
      • It is appropriate to estimate tasks both during iteration planning and throughout the iteration. [Agile Estimating and Planning. Mike Cohn.]
    • See eXtreme Programming (XP) and Planning poker

    User story triangulation

    Validation

    Value

    • Pareto :
      • The pareto rule stipulates that 80% of value derives from 20% of the work. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
    • Backlog :

    Value-driven delivery

    • Value-driven delivery is an overarching principle for Agile projects.
      • Projects are carried out to realize values (e.g. economic benefits, competitive advantages, reducing risks, regulatory compliance, etc.)

    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 and progress

    • Because value is delivered incrementally and iteratively through iterations, value and progress is typically measured at the end of each iteration. [The Art of Agile Development. James Shore.]

    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 prioritization 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 based prioritization

    • Value based prioritization is to organize things so that the most important ones that deliver values are to be dealt with first
    • Value based prioritization is based on :
      • Compliance
      • Customer valued prioritization
      • ROI
      • IRR
      • PV
      • NPV
      • IRR and NPV
      • Minimum marketable feature (MMF)
      • Relative prioritization/ranking
      • Value

    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 Prioritization Schemes

    • simple schemes
      • rank from high to low (priority 1, 2, 3, …)
    • MoSCoW prioritization scheme
      • Must have, Should have, Could have, Won’t have this time or Would like to have, in future
    • Monopoly money
      • ask customers to give out (fake) money to individual business features in order to compare the relative priority
    • 100-Point method
      • customers are allowed to give, in total 100 points, to various features
    • Dot voting / Multi-voting
      • everyone is given a limited number of dots (~20% of the number of all options) to vote on the options
    • Kano analysis
      • plot the features on a graph with axes as Need Fulfilled / Not fulfilled vs Satisfied / Dissatisfied, each feature will then be classified as “exciters, satisfiers, dissatisfiers, indifferent”. Excitersare of highest values.
    • Requirements Prioritization model
      • rate each feature by benefits for having, penalty for not having, cost of producing, risks, etc. and calculate a score using a pre-defined weighted formula
    • CARVER
      • (Criticality, Accessibility, Return, Vulnerability, Effect, and Recognizability) relative to the objective and mission of the project
    • Criticality
      • how important to be done upfront
    • Accessibility
      • can work on it immediately? or depends on other work / skills?
    • Return
      • ROI / NPV / IRR
    • Vulnerability
      • how easy to achieve the desired results?
    • Effect
      • what are the effects on the project (help moving towards the goal of the project)?
    • Recognizability
      • have the goals been clearly identified?

    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.]
    • See Value stream analysis and value-stream mapping

    Variance and trend analysis

    • variance is the measure of how far apart things are (how much the data vary from one another)
      • e.g. the distribution of data points, small variance indicates the data tend to be close to the mean (expected value)
    • trend analysis provides insights into the future which is more important for problem detection
      • though measurements are lagging, they will provide insights should trends be spotted
    • variance and trend analysis is important for controlling (problem detection) and continuous improvement, e.g the process to ensure quality
    • Control limits for Agile projects
      • by plotting the time to delivery / Velocity / escaped defects / etc. as a control chart
      • if some data fall outside the upper / lower control limits, a root cause analysis should be performed to rectify the issue
        • common cause – systematic issue, need to be dealt with through trend analysis
        • special cause – happens once only due to special reasons
      • another example is the WIP limit in Kanban Boards

    Velocity

    • As the name implies, the Velocity is a measure of how fast work is progressing within a Sprint or iteration.
      • For most typical teams, this is measured as the number of story points (a measure of effort) completed within a time-boxed iteration.
    • Velocity is an optional, but often used, indication of the amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Developers for use within the Scrum Team.
    • Velocity is a capacity planning tool used in Agile project
      • a unit to measure the speed of the team (e.g. the number of story points in each iteration) which is very useful for planning future releases
      • partially finished tasks in an iteration will NOT be counted towards velocity
      • e.g. if a task with 100 story points is 90% complete, it will contribute 0 story point to the iteration
        • usually defined as the number of story points that are completed in an iteration
          • Velocity usually increases gradually over the first few iterations as the team becomes more “performing” but stabilises afterwards as the product becomes more complicated (more bugs, more documentations, more dependencies, etc.)
    • Velocity is a measure of the number of User Story points or stories completed per iteration.
      • An agile team can use its previous Velocity values as a method of estimating how many User Story points it may complete in the next iteration. [Agile Estimating and Planning. Mike Cohn.]
    • Velocity is the rate of development progress.
      • Usually expressed as stories completed (and tested) per iteration.
      • The primary measure of development speed.
    • The team uses its Velocity to pick the number of User Stories to develop in the upcoming iteration. [The Art of Agile Development. James Shore.]
      • We calculate cost and time budget at release level based on estimated size and Velocity.
    • If a User Story is not accepted by the Product Owner during a Sprint Review, the team should not mark the User Story as complete and collaborate with the product owner to determine if and when the User Story should be completed. [Agile Estimating and Planning. Mike Cohn.]
      • User Story points for partially completed stories are not included in the Velocity metric. [Agile Estimating and Planning. Mike Cohn.]
    • Velocity alone is insufficient for comparing productivity among two or more agile teams.
      • This is because no two teams share the same definition of a story point. [Agile Estimating and Planning. Mike Cohn.]
    • Estimating how many user story points a team can complete in a sprint/iteration should be based upon its previous iterations, if possible.
      • If Kyle’s team estimated 45 story points in its first sprint but completed only 30 story points, it would be wise to estimate no more than 30 for its next sprint/iteration. [Agile Estimating and Planning. Mike Cohn.]
    • Velocity measures a team’s capacity for work per iteration.
      • This helps us to determine the maximum workload of a team.
      • Velocity varies most in the first few iterations and then begins to stabilize.

    Verification

    • Verification is the confirmation that a product performs as specified by a customer (e.g. as indicated by a user story),

    Verification and validation

    • Because each iteration typically produces a working product that is built and integrated and iterations are typically two to four weeks in length, there is frequent verification and validation to ensure product quality.
      • Verification is the confirmation that a product performs as specified by a customer (e.g. as indicated by a user story),
      • Validation is the confirmation that a product behaves as desired (i.e., meets the customer’s need).
      • Sometimes a product may be built and integrated to specification – that is, it can be verified – but it does not meet the intent of the customer – that is, it cannot be validated.
      • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
    • Agile frequent verification and validation

    Version Control

    Vertical-market software

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

    Waste

    • What is waste ?
      • Waste comes in three main forms :
        • Mura
          • waste due to variation
        • Muri
          • waste due to overburdening or stressing the people, equipment or system
        • Muda
          • also known as the “seven forms of waste”
            • Transportation,
            • Inventory,
            • Motion,
            • Waiting,
            • Over-production,
            • Over-processing,
            • Defects
          • Taxes are not one of the seven wastes.
            • Taxes are regulatory obligation and could not be considered as waste.
    • Waste can take many forms and can be remembered using the pneumonic device WIDETOM :
      • W – waiting;
      • I – inventory;
      • D – defects;
      • E – extra processing;
      • T – transportation;
      • O – overproduction;
      • M – motion.

    WET solutions

    • Violations of DRY principle are typically referred to as WET solutions.
      • Wet Solutions which stands for either “write everything twice”, “we enjoy typing” or “waste everyone’s time”.
      • It is difficult to manage such code and if the logic changes, then Developers have to make changes in all the places where they have written the code, thereby wasting everyone’s time.
    • See Scrum and Coding Principles

    White-Box Testing

    • White-Box Testing is a software testing method in which the internal structure/design/implementation of the item being tested is known to the tester.
      • The tester chooses inputs to exercise paths through the code and determines the appropriate outputs.
      • Also, it implies testing based on an analysis of the internal structure of the component or system.
      • This method is named so because the software program, in the eyes of the tester, is like a white/transparent box; inside which one clearly sees.
    • White-Box Testing :
      • White Box testing, also known as Clear Box Testing, Open Box Testing, Glass-Box Testing, Transparent Box Testing, Code-Based Testing or Structural Testing, is a software testing method in which the internal structure/design/implementation of the item being tested is known to the tester.

    Wide band Delphi

    • Wide band Delphi is a group estimation technique.
      • The Wideband Delphi estimation method is a consensus-based technique for estimating effort.
      • It derives from the Delphi method which was developed in the 1950-1960s at the RAND Corporation as a forecasting tool.
      • It has since been adapted across many industries to estimate many kinds of tasks, ranging from statistical data collection results to sales and marketing forecasts.
      • Barry Boehm and John A. Farquhar originated the Wideband variant of the Delphi method in the 1970s.
      • They called it « wideband » because, compared to the existing delphi method, the new method involved greater interaction and more communication between those participating.
      • The method was popularized by Boehm’s book Software Engineering Economics (1981).
    • Original steps :
      • Coordinator presents each expert with a specification and an estimation form.
      • Coordinator calls a group meeting in which the experts discuss estimation issues with the coordinator and each other.
      • Experts fill out forms anonymously.
      • Coordinator prepares and distributes a summary of the estimates
      • Coordinator calls a group meeting, specifically focusing on having the experts discuss points where their estimates vary widely
      • Experts fill out forms, again anonymously, and steps 4 to 6 are iterated for as many rounds as appropriate.
    • Where is it effective ?
      • For making top-down estimates in situations where there are a lot of unknowns or various kinds of domain knowledge required.
      • Especially useful for early estimates of large, not-yet-well-understood projects — estimates upon which we base our go/no-go decisions and early expectation-setting for upper management and customers.
    • How does it work?
      • step 1 : Schedule the estimation meeting for a particular project or set of projects.
        • The estimators should be team members (and possibly other stakeholders) who are very knowledgeable about the project, and from whom you need buy-in for the schedule of the project.
        • 3-5 estimators is the sweet spot, although much larger groups can work, by breaking them into 3-5 person sub-groups and then combining those estimates.
      • step 2 : Describe what the group is estimating.
        • What part of the project, goals, or outcome are we estimating?
        • What types of resources are we going to include?
        • What units (ideal man-days or man-months, story points, etc.) will we use?
      • step 3 : Ask everyone to estimate individually and privately using their best, instinctual judgement on the estimate.
        • Give them enough time (5-20 minutes) to do this work quietly.
        • Once people are familiar, you may be able to ask them to do this before the estimation meeting.
        • Ask them also to take note of the assumptions and major pieces of work that led to the estimate — they’ll use these later in the group discussion.
        • The private/anonymous aspect of this first round of estimates is important: we’re specifically empowering each person to express their gut instinct, and not be influenced by group think yet.
      • step 4 : Show the results on a spreadsheet or whiteboard, and discuss.
        • The group can see how divergent or convergent their estimates are.
        • Ask each person (but especially the high/low or other interesting estimators) to explain how they got to their estimate — major assumptions, things included, etc.
        • People will be reminded of things they forgot to include in their estimates.
        • They’ll also be forced to confront different assumptions (which you may be able to quickly decide upon).
        • All of which will improve future rounds of estimates.
      • Repeat steps 3 & 4 for a total of 2-3 rounds.
        • After round one, anonymity is dropped and discussions can be short (the moderator should make decisions on behalf of group, for expediency and just for the purposes of the estimate).
        • Often only 2 rounds total are needed to see estimates converge somewhat.
        • A common effect is estimates converge together and up as people realize from the discussions the things they missed from their initial estimates.

    Wideband Delphi Estimating

    • similar to the Delphi technique but discussion about details of the requirements is allowed in the beginning to allow each individual to have a common understanding of the scope of the tasks, each participant will then try to give an estimate for the user stories, etc. with relative sizing on their own; repeat the process until a consensus is reached

    WIDETOM

    • Waste can take many forms and can be remembered using the pneumonic device WIDETOM :
      • W – waiting;
      • I – inventory;
      • D – defects;
      • E – extra processing;
      • T – transportation;
      • O – overproduction;
      • M – motion.
    • See Value stream analysis and value-stream mapping

    Work in Process (WIP)

    • Work in Progress (WIP) is the number of work items started but not finished.
      • The team can use the WIP metric to provide transparency about their progress towards reducing their WIP and improving their flow.
      • Note that there is a difference between the WIP metric and the policies a Scrum Team uses to limit WIP.
      • See Scrum and Kanban
    • A lean manufacturing philosophy is to eliminate waste.
      • One defined waste type in the lean philosophy is inventory, which is also referred to as work in process (WIP).

    Wireframes

    • Wireframes
      • Wireframe is a sketch graphical presentations of how the requirements are fulfilled (usually as interface designs), can act as a kind of fast requirement documentation
        • If there are mismatches in understanding, wireframes (virtual screens & flows between the screens) serves as visual for the stakeholder to refer and adjust until they achieve consensus.
        • Wireframes are a form of « low-fidelity prototyping », they are a quick and cheep way to get a feedback on something.

    Whole Team

    • Whole Team means that all skills that are required to turn the selected User Stories into a releasable software must be on the team, present across all the team members.

    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).

    Work in Process (WIP)

    • Work in Progress (WIP) is the number of work items started but not finished.
      • The team can use the WIP metric to provide transparency about their progress towards reducing their WIP and improving their flow.
      • Note that there is a difference between the WIP metric and the policies a Scrum Team uses to limit WIP.
      • See Scrum and Kanban
    • A lean manufacturing philosophy is to eliminate waste.
      • One defined waste type in the lean philosophy is inventory, which is also referred to as work in process (WIP).

    Workshop

    • workshops can be a great way to encourage active participation of all stakeholders
      • better make use of low-tech high-touch tools like whiteboard or post-its to show ideas

    Work Item Age

    • The amount of time between when a work item started and the current time.

    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 eXtreme Programming (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.
    • YAGNI stands for “You aren’t going to need it“ or “You ain’t gonna need it.”
      • YAGNI means always implement things when you actually need them, never when you just foresee that you need them. It is a principle behind the eXtreme Programming (XP) practice of “do the simplest thing that could possibly work.”
    • See Scrum and Coding Principles

    The first version of this Agile dictionary was wrottten by Mike Griffiths and completed by us in 2021. Mike Griffiths is 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

    Updated : 13/10/2021

    admin5315

    View all posts by admin5315 →

    You might also like

    Scrum framework : Product Backlog Management

    Agile estimation

    Agile cycle time and lead time

    Leave a Reply

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