Free PMI ACP Notes

Agile Tooling

Agile Tooling refers to hi-tech or low-tech software or artifacts designed to increase the sense of team and to encourage participation among the members. Examples include version control software, collaboration software, or video conferencing for distributed teams.

wireframe

A wireframe is a "low fidelity” prototype. This non-graphical artifact shows the skeleton of a screen, representing its structure and basic layout. It contains and localizes contents, features, navigation tools and interactions available to the user. It is often used as a communication tool serving as an element of conversation and confirmation of Agile user stories.

Domain Model

Domain Model illustrates: the business structure, its entities, and their relationships.

supply system

A supply system where items are produced at the request of the customer is called a Pull System.

Ethnocentrism

An attitude that one's group is superior to others is called an Ethnocentrism.

Grooming

Grooming is an ongoing collaborative effort led by the Product Owner and including significant participation from internal and external stakeholders as well as the Scrum Master and development Team.

Decision framing

Decision framing focuses on who gets involved in the decision process. Managers who make decisions without input from subordinates and peers make poor decisions. Engineers who make decisions without input from managers and peers make poor decisions. Who makes the decision is less important than getting the right people involved in the decision process.

Relative Weighting

An approach that is similar to Kano’s in that considers both the positive benefit of the presence of a feature and the negative impact of its absence is Relative Weighting approach.

Ishikawa or fishbone diagrams or Cause-and-effect

Cause-and-effect diagrams - also called Ishikawa or fishbone diagrams - show the relationship between the effects of problems and their causes. Kauru Ishikawa developed cause-and-effect diagrams.Ishikawa diagrams show the steps needed to identify the risk

Morale Barometer Metric

A metric for the health of Team dynamics is called Morale Barometer.

Mind map

A mind map is a technique is used to create a graphical diagram to represent  words, ideas, tasks, or other items linked to and arranged around a central key word or idea

A mind map is a graphical technique of taking notes and visualizing thoughts using a radiant structure.

Story mapping

Story mapping is a technique popularized by Jeff Putton that takes a user-centric perspective for generating a set of user stories. The basic idea is to decompose high-level user activity into a workflow that can be further decomposed into a set of detail

Expert Judgment

Expert Judgment does not need seeking consensus as it is not a collaborative effort.

The Delphi technique

The Delphi technique is a commonly used tool to secure expert
judgment while initiating a project. Peer review is a project selection tool, Expected value is a method quantitative risk analysis, and 'WBS' is a project-planning tool.

Expert opinion

approach is less useful on agile projects than on traditional projects. On an agile project, estimates are assigned to user stories or other user-valued functionality. Developing this functionality is likely to require a variety of skills normally performed by more than one person. This makes it difficult to find suitable experts who can assess the effort across all disciplines. On a traditional project for which estimates are associated with tasks this is not as significant of a problem because each task is likely performed by one person.

Parkinson’s Law

Parkinson’s Law states "Work expands so as to fill the time available for its completion." In Agile processes, we use the notion of a "timebox" or "spike" to deal with this sort of work.

Pareto Diagram

A Pareto Diagram is a specific kind of histogram, ordered by frequency of occurrence.

Crystal methodologies

Alistair Cockburn indexes the Crystal methodologies by color: Clear, Yellow, Orange, Red, Magenta, Blue, Violet, and so on. The other restriction on Crystal methodologies is that they address only colocated teams. As discussed earlier, none of the distributed and offshore development projects would count as methodologically successful. The only recommendation I have for such projects is to put the team together at one location. Two values are that Crystal methodologies are intrinsically People- and communication-centric and Highly tolerant.

parking lot

A "parking lot" diagram provides the development team, the customer team, and management with a useful overview of value and scope status. Whereas the typical Gantt charts emphasize schedule and tasks, a parking lot diagram emphasizes capability and story progress first and foremost.

Value Stream Maps

Value Stream Maps exist for two purposes: to help organizations identify and end wasteful activities. Finding problems and creating a more efficient process isn't easy; even the best organization can be made more efficient and effective. But bringing about substantive organizational change that actually eliminates waste is a tall order.

As for the value stream map itself, it is actually a form of a flowchart.

Delphi technique

The Delphi technique is a facilitated process to reach a consensus of experts using questions and feedback. Only the facilitator is aware of who is participating. It is a technique to reduce bias and prevent any one person from exerting under influence

Root-cause analysis

You can use root-cause analysis any time you notice a problem—when you find a bug, when you notice a mistake, as you’re navigating, and in retrospectives. It needs a few seconds. Keep your brain turned on and use root-cause analysis all the time.

Root cause analysis looks beyond the symptoms to get to the core issue that is causing the problem. One way this is accomplished is through Cause and Effect Diagram. It is also known as Ishikawa Diagram.

Virginia Satir’s

Change models like Virginia Satir’s show that once you start a change initiative, a drop in productivity is highly probable due to the period of resistance and chaos. Your objective is to shorten this phase by completing all your preparation efforts before the transition starts, not during the transition.

Documents

Documents support communication and collaboration, enhance knowledge transfer, preserve historical information, assist ongoing product enhancement, and fulfill regulatory and legal requirements. They are not unimportant, just less important than working versions of the product.

Affinity estimating

Affinity estimating provides a way to rapidly estimate your backlog.

Spider Web

All products and services coexist within a larger context of an ecosystem of related, complementary, and even competitive products and services. Unfortunately, product designers often fail to recognize and leverage the relationships within this ecosystem. This often means they miss innovative opportunities to create happier customers and capture more revenue. The Spider Web game helps you understand how your customer sees the relationships between your product and service and other products and services. You can then use this information to capture more revenue by creating innovations around these relationships. This is a description of the Spider Web innovation game.

planned

The project is planned as normal for delivery of the entire set of functionality; however, some amount of the work is optional and will only be included if time permits. The optional work is developed last, only after the mandatory work is complete.

Analysis Task

A task that provides insight on requirements, which in turn leads to other tasks is called Analysis Task.

Padding

Arbitrarily added time to an estimate

Exploratory testing

Testing is used to look for surprises and gaps in the software and provides an after-the-fact check on the team's practices

Rolling Wave Planning

Rolling Wave Planning indicates a technique used to plan in stages instead of doing so early in the project.

Theory X,Y

In Theory X, employees are assumed to be lazy and shiftless and will avoid work and responsibility if they can. Theory Y proposes that people want to do well and are self-motivated to succeed if given the opportunity. Theory Y is far removed from Frederick Taylor's early work in which he asserted that extrinsic motivators (rewards and punishments) were required to extract any effort beyond the minimum allowed for continued employment

Context-free questions

Context-free questions do not imply an answer ("When did you stop beating your wife?") so the respondent does not feel a need to give the "right" answer. Open-ended questions allow detailed responses that go beyond a simple yes or no. Open-ended, context-free questions are best because they do not influence the response and they allow a broader range of responses than yes or no.

Kaizen

Kaizen is strongly aligned with Agile in the way it encourages changes from the workers rather than asking management what should be changed. Therefore, it's strongly aligned with Retrospective Meeting in Scrum.

Sashimi

Similar to the way every other slice tastes. Scrum uses the sashimi technique to require that every slice of functionality created by the developers be complete.

Metaphor

The Scrum Master is a facilitator, coach, mentor and bulldozer! A Scrum Master is often compared to a sheepdog, responsible for keeping the flock together and the wolves away. Chicken refers to those outside the three Scrum roles.

CRACK

An effective product owner is Committed, Responsible, Authorized, Collaborative, and Knowledgeable(CRACK)

Risk Map

One of the best ways to visually display risks in a succinct manner is to use a Risk Map. On the vertical axis you have the probably of a given risk occurring, that is, the likelihood that the risk will materialize and become an Issue. On the horizontal axis we have the impact that the risk will have on the project or program should it materialize..

Feature card

A feature card starts a requirements conversation. An FSP tries to cover all requirements immediately. A feature card is used to record conversations. An FSP doesn't include conversations but focuses on documenting how a documented business requirement will be met. A feature card focuses on verbal communication, common understanding, and synchronizing the team on the customer goals. An FSP focuses on documenting the functional details and having team members read the FSP to understand what they should do.

Estimates are not created by a single individual on the team. Agile teams do not rely on a single expert to estimate. Despite well-known evidence that estimates prepared by those who will do the work are better than estimates prepared by anyone else, estimates are best derived collaboratively by the team, which includes those who will do the work.

Force field analysis

Force field analysis is a management technique developed by Kurt Lewin, a pioneer in the field of social sciences, for diagnosing situations. Lewin assumes that in any situation there are both driving and restraining forces that influence any change that may occur.

Gardeners prune trees

Gardeners prune trees to control their growth. Sometimes the pruning is artistic, and we end up with shrubs shaped like animals or interesting abstract shapes. Much of the time the pruning is designed to build a balanced tree that yields high-quality fruit. The process isn't about "cutting," it is about "shaping." Use this metaphor to help create the product your customers desire.

Hardening iteration

Many agile teams will set aside an iteration at the end of the project to use for "hardening" (preparation for final rollout of the product). Note that this is not a bug-fixing iteration! For an internal release, this hardening iteration may consist of a variety of production-readiness activities, whereas for an external release, additional tasks such as capturing final screenshots for promotional materials and lining up production facilities might be items to consider.

Inter-team Commitment Story

As project size increases we need similar mechanisms to allow feature teams to work together with minimal management involvement. This mechanism is the Inter-team Commitment Story, a brief written agreement between feature teams.

Ideal Time

On a software project, ideal time differs from elapsed time not because of timeouts, incomplete passes, and injuries but because of the natural overhead we experience every day. On any given day, in addition to working on the planned activities of a project, a team member may spend time answering email, making a support call to a vendor, interviewing a candidate for the open analyst position, and in two meetings.

Osmotic communication

When osmotic communication is in place, questions and answers flow naturally and with surprisingly little disturbance among the team.

Healthy coaching

1.    The Magician,

2.    The Wise Fool, and

3.       The Dreamer

Situational Leadership.

A technique where a manager adjusts personal interactions and approach to the team according to the current team dynamic is called a Situational Leadership.

Requirement

The results of the requirements specification process, whatever the engineering discipline involved, should be documented as a hierarchy such as product, platform, group, and component. For business software applications, these categories could be application, business area, capability, feature, and story. Small software products might use only the story level, whereas large industrial products may use the entire hierarchy.

Application Lifecycle Management.

Focused and involved management of the entire software development process, end to end is called a Application Lifecycle Management.

Technique commonly Automate Build

A technique commonly used in the context of crafting automated unit tests and automated builds. It consists of instantiating a test-specific version of a software component (typically a class), which instead of the normal behaviors provides precomputed results, and often also checks that it’s invoked as expected by the objects being tested. For instance, the "mock" version of a database component will a) provide "canned" answers to database queries, instead of connecting to a real live database, and b) verify that the database is being accessed in the manner expected and stipulated in the test.

Fractional assignment

Some organizations like to assign people to multiple projects simultaneously.

Stakeholder analysis

One of the activities that helps is a process known as stakeholder analysis. When performing stakeholder analysis, the stakeholders are identified, and their interest in the project is understood. All of this information is captured in a stakeholder register, which is a simple artifact.

Complexity factors

complexity factors include team size, team distribution, mission criticality, and domain knowledge gaps, whereas uncertainty factors include market uncertainty, technical uncertainty, and project duration.

Just In Time

Just In Time is a an inventory management process that lets a company have little or no excess inventory in stock, other than what they need to build existing order.

Multitasking

Multitasking exacts a horrible toll on productivity. Clark and Wheelwright (1993) studied the effects of multitasking and found that the time an individual spends on value adding work drops rapidly when the individual is working on more than two tasks.

Factor of reducing turnover risk in Agile project

The impact of turnover can be reduced by cross training (which rarely happens) and documentation (which coveys very little of the tacit knowledge that is so critical to success). Agile projects have built-in turnover mitigation because of the emphasis on collaboration. In software development, for example, the use of pair programming has demonstrated better knowledge sharing within the team, which reduces the impact of turnover. Employee morale generally improves in an agile environment because of the emphasis on self-organization and the excitement of frequent iteration delivery of working products.

Extrinsic and intrinsic quality

Customer quality (which is extrinsic or external) delivers value in the short term. Technical quality (which is intrinsic or internal) enables continuous delivery of value over time. Poor quality work results in unreliable products,  but more critically, it results in products that are far less responsive to future customer needs.

Soft Skills

It's a set of skills that influence how we interact with each other. It includes such abilities as effective communication, creativity, analytical thinking, diplomacy, flexibility, change-readiness, and problem solving, leadership, team building, and listening skills

Schedule Based Planning

Is a release planning method that focuses on time rather than features or scope.The place where work is actively being done is sometimes called Gemba.

FDD

FDD prefers individual code ownership and seeks to avoid refactoring by focusing on domain modeling. FDD is also scalable and works with multiple teams or large teams. Scrum and XP prefer shared code ownership. TDD is not an Agile methodology, but an engineering technique in XP.

Analogous Estimation.

An estimation technique which compares a project's scope with those of previous projects is called Analogous Estimation.

Scope creep

Scope creep is also referred to as "requirements inflation," and the longer the delivery cycle the more likely additional requirements or changes to existing requirements will occur.

Timboxing and WIP

Timboxing is a technique of lmiting the amount of WIP. WIP represents an inventory of work that is started but not yet finished. Failing to properly manage if can have serious economic consequences. Because the team will plan to work on only those items it believes it can start and finish withn the sprint, timeboxing establishes a WIP limit each sprint.

feature breakdown structure (FBS)

During detailed planning, agile development favors a feature breakdown structure (FBS) approach instead of the work breakdown structure (WBS) used in waterfall development approaches

Advantage

·          They allow communication between the customer and the development team in terms both   
  can understand.

·         They allow the customer to prioritize the team's work based on business value.

·          They allow tracking of work against the actual business value produced.

Stories and Use cases

One of the most obvious differences between stories and use cases is their scope. Both are sized to deliver business value, but stories are kept smaller in scope because we place constraints on their size (such as no more than ten days of development work) so that they may be used in scheduling work. A use case almost always covers a much larger scope than a story.

User stories or other items that are likely to be more distant than a few iterations can be left as epics or themes. That's why they are primaly located at the bottom.

Epic is often called Capability.

Where the user stories of a release plan are estimated in story points or ideal days, the tasks on the iteration plan are estimated in ideal hours.

Advantages of user stories

Some of the advantages of user stories over alternative approaches are: User stories emphasize verbal communication, User stories are comprehensible by everyone, User stories are the right size for planning, User stories work for iterative development, User stories encourage deferring detail, User stories support opportunistic design, User stories encourage participatory design, User stories build up tacit knowledge.

User stories originated as part of Extreme Programming. Naturally, stories fit perfectly with the other practices of Extreme Programming. However, stories also work well as the requirements approach for other processes.

User stories may and should be supplemented with whatever other written information helps provide clarity against what is desired.

User stories that will be worked on in the near future (the next few iterations) need to be small enough that they can be completed in a single iteration. These items should be estimated within one order of magnitude

When a story (possibly an epic) is disaggregated into its constituent stories, the sum of the estimates for the individual stories does not need to equal the estimate of the initial story or epic.

The front of a story card contains the story and notes about open questions while the back of the card contains details about the story in the form of tests that will prove whether or not it works as expected.

Theme

A set of related user stories may be combined together (usually by a paper clip if working with note cards) and treated as a single entity for either estimating or release planning. Such a set of user stories is referred to as a theme.

Scrum

User Stories, Features, Use Cases can be successfully used in Scrum, but it's not required. This question refers to the best practices and core of the Scrum that can be found in the Scrum Guide

Innovation Games or Games of collaborative play

Innovation Games possess several qualities that stand out among the various approaches. One quality is reflected in their name: Innovation Games. You can refer to them as "games of collaborative play," This can be contrasted with traditional surveys and focus groups, which are often not designed to be fun and may not include a heavy emphasis on collaboration

Iterative development

Iterative development acknowledges that we will probably get things wrong before we get them right and that we will do things poorly before we do them well. As such, iterative development is a planned rework strategy.

Iterations

Iterations are timeboxed, so schedule and budget are always fixed too. During iteration planning we talk about the tasks that will be needed to transform a feature request into working and tested software

Status meeting

In agile projects, the "status meeting"—or iteration review—is much more meaningful because, instead of reading a document that tells stakeholders the progress of the project, they can actually look at working software

Feature overrun

Frequently a feature will surprise you when you start developing it. The code takes longer than expected, or you underestimated complexity. Here are some of the ways teams adapt to feature overrun: Work with the customer to prioritize the functionality in the feature and potentially reduce the scope, Accept the discovery and continue the work into the next iteration, Cancel the feature, and re-evaluate the feasibility of the project

Technical practice used in Agile development

The four technical practices —simple design, continuous integration, ruthless automated testing, and opportunistic refactoring— work in concert with each other. Although there are many other technical practices, these four are critical to adaptability

Brundown Chart

Progress of the iteration can be determined from this graph line. A flat line means that either the team is not updating its remaining work hours, or there is an obstacle preventing progress. An upward spike means that new work was discovered

Drawing a trend line from previous completed work on a release burndown chart indicates.  Assuming no changes to the current Sprint Backlog, a trend line from previously completed work indicates when the remaining work will be completed.

Sprint Burndown

 The Sprint Burndown is what remains to be completed in Sprint Backlog by the Scrum Team within the Sprint plan.

The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burndown, for example the release burndown chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the alternative release burndown chart,^[19] which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline.

Project Portfolio Backlog

Project Portfolio Backlog lists current and potential projects

Velocity

Velocity is used as a planning tool and as a team diagnostic metric. It should not be used as a performance metric in an attempt to judge team productivity. When misused in this way, velocity can motivate wasteful and dangerous behavior.

One of the challenges of planning a release is estimating the velocity of the team. You have the following three options: Use historical values, Run an iteration, Make a forecast.

Release backlog

“A collaborative exercise of placing user stories into iterations by using sticky notes and flip chart paper, "filling up" each iteration (or steel box) with no more than ten points' worth of stories in each “

This set of features, called the "release backlog," can be used as a baseline by which project progress is measured. The team was involved in Release Planning.

Release Burndown

The Release Burndown is what remains to be completed in Product Backlog by the Scrum Team within the release plan.

Release plan

The product of the Speculate phase is a release plan based on capabilities or stories (features) to be delivered rather than activities (as in traditional project plans). The release plan utilizes information about the product's specification, platform architecture, resources, risk analysis, business con

The release planning usually requires no more than 15-20% of the product effort

Sprint planning meeting^[13][14]

At the beginning of the sprint cycle (every 7–30 days), a “Sprint planning meeting” is held.

·         Select what work is to be done

·         Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team

·         Identify and communicate how much of the work is likely to be done during the current sprint

·         Eight-hour time limit

·        (1st four hours) Entire team:^[15] dialog for prioritizing the Product Backlog

·        (2nd four hours) Development Team:^[16] hashing out a plan for the Sprint, resulting in the Sprint Backlog

At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective”

Sprint review meeting^[17]

·         Review the work that was completed and not completed

·         Present the completed work to the stakeholders (a.k.a. “the demo”)

·         Incomplete work cannot be demonstrated

·         Four-hour time limit

Sprint retrospective^[18]

·         All team members reflect on the past sprint

·         Make continuous process improvements

·         Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?

·         Three-hour time limit

·         This meeting is facilitated by the Scrum Master

Scrum Artifacts

Product Backlog

The product backlog is an ordered list of "requirements" that is maintained for a product. It contains Product Backlog Items that are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed,

The product backlog is the “What” that will be built, sorted in the relative order it should be built in. It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the stories on the backlog for the Development Team.

The product backlog contains rough estimates of both business value and development effort, these values are often stated in story points using a rounded Fibonaccisequence. Those estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items. For example, if the “add spellcheck” and “add table support” features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI (Return on Investment) is higher.

The Product Backlog, and business value of each listed item is the responsibility of the Product Owner. The estimated effort to complete each backlog item is, however, determined by the Development Team. The team contributes by estimating Items and User-Stories, either in Story-points or in estimated hours.

                

                Sprint Backlog

The sprint backlog is the list of work the Development Team must address during the next sprint. The list is derived by selecting stories/features from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. This is done by the Development Team asking "Can we also do this?" and adding stories/features to the sprint backlog. The Development Team should keep in mind the velocity of its previous Sprints (total story points completed from each of the last sprints stories) when selecting stories/features for the new sprint, and use this number as a guide line of how much "effort" they can complete.

The stories/features are broken down into tasks by the Development Team, which, as a best practice, should normally be between four and sixteen hours of work. With this level of detail the Development Team understands exactly what to do, and potentially, anyone can pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed during the daily scrum, according to the set priority and the Development Team member skills. This promotes self-organization of the Development Team, and developer buy-in.

The sprint backlog is the property of the Development Team, and all included estimates are provided by the Development Team. Often an accompanyingtask board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.

Declaration of Independence(DoI)

A series of principles developed by the Agile Project Leadership Network is called Declaration of Independence.

Discounted Payback Period

Discounted Payback Period is an adjustment of the cash flow stream to account for the time value of money.

Schedule Performance Index (SPI)

A Ration of Earned Value and Planned Value that can be used to calculate when a project will be completed, or how a project is progressing is called Schedule Performance Index (SPI)

DSDM
DSDM, or Dynamic Systems Development Method, is an iterative and incremental methodology popular in Europe. It combines a project management lifecycle and a product development lifecycle into one process. It is composed of three phases: pre-project, project lifecycle, and post-project phase

DSDM projects requirements are sorted into four categories: Must Have, Should Have, Could Have, Won’t Have. DSDM refers to this sorting as the MoSCoW rules

Agile Principle

Go fast but never hurry

All agile approaches focus on empowered, self-managing teams; autonomous teams do not need the day-to-day intervention of management. Instead, if management protects a team from outside interference, and focuses on removing obstacles in the way of creating product, teams become highly effective and productive

Project Charter

ü  Its primary use is to authorize the start of the project

ü  It provides the project manager with authority to apply resources and expend money on project

ü  The Project Charter can be created by the person external to the project, responsible for the authorization of the work, or that person can delegate the creation of the Project Charter to the project manager

Product managers

Product managers control which features are included in the product. Development engineers control how features are designed and implemented. Product managers wouldn't have the authority to say, "We're running behind; let's cut testing time." Instead, they could only say, "We're running behind, let's cut features 34 and 68." Similarly, the development team couldn't arbitrarily add a feature because "it would be way cool."

Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of Done product at the end of each Sprint.Turn the Product Backlog items it selects into an increment of potentially shippable product functionality.

The Scrum Team is the sole owner of the Sprint Backlog.

Definition of Done

When the Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the “Definition of Done” for the Scrum Team and is used to assess when work is complete on the product Increment. The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning Meeting. Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.

The quality criteria are captured in the definition of done.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan for delivering the product Increment and realizing the Sprint Goal. It can contain different content types. The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, and estimate

Non-linear sequences

sequences are best for estimating user stories in Agile Team

Non-linear sequences work well because they reflect the greater uncertainty associated with estimates for larger units of work. Either sequence works well although my slight personal preference is for the first. Fibonacci sequence is an example of such a sequence

XP-Customer

On-Site Customers are responsible for making business decisions. The on-site customers point the project in the right direction by clarifying the project vision, creating stories, constructing a release plan, and managing risks.

Agile coach

The agile coach facilitates by creating a “container” for the team to fill up with their astounding ideas and innovations. The container, often a set of agenda questions or some other lightweight (and flexible) structure, gives the team just enough of a frame to stay on their purpose and promotes an environment for richer interaction, a place where fantastic ideas can be heard. The coach creates the container; the team creates the content.

Agile Manifesto –High Priority

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This principle underscores the focus of delivering value to the customer. At the end of the day, it is this philosophy of customer satisfaction that drives agile teams.

In high-performance teams, "the leaders manage the principles, and the principles manage the team".

Employ minimally sufficient - is an Agile Principle.

Principle three of Agile Manifesto mandates that "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale".

Scrum Team

Self-organization is not an option in Scrum; it is a core principle. Without this, high performing teams will not happen. Self-organization does not at all imply a laissez-faire approach; on the contrary, self-organized teams are highly disciplined. They are encouraged to take reasonable risks and to learn through failure and self-reflection. High trust and high commitment is an automatic outcome of truly self-organizing teams.

Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of "Done" product ensure a potentially useful version of working product is always available.

A Swarm is a temporary group of team members that works together on one story to bring it to completion.

The burn rate is the cost of the Agile team, or the rate at which is consumes resources.

Product Owner

Successful agile product ownership is more complex than just managing User Stories and Product Backlog. The Product Owner maximizes the Return on Investment (ROI) and optimizes the Total Cost of Ownership (TCO).

The product owner leads the development effort to create a product that generates the desired benefits. This often includes creating the product vision; grooming the product backlog; planning the release; involving customers, users, and other stakeholders; managing the budget; preparing the product launch; attending the Scrum meetings; and collaborating with the team.

Good Product Owners understand the collaborative grooming fosters an important dialogue among all participants and leverages the collective intelligence and perspectives of a diferce group of individuals. Good Product Owners also know that by involving the diverce team members in the grooming, they ensure that everyone will have a clearer, shared understanding of the product backlog, so less time will be wasted in miscommunications and handoffs. Such collaborative efforts also go a long way toward bridging the gap between business and technical people.

The Product Owner and The Development team provide clarification of the Backlog Items During Planning Meeting and Sprint as it might be not fully known everything or specified at the start of the sprint.

The Product Owner acts as the single voice of stakeholders and represent their needs. Running Daily Scrum is a responsibility of the Scrum Master. Updating a Sprint Burndown is a responsibility of the Development Team as well as prioritizing activities.

Process changes are owned by the team, whereas product changes are owned by the customer

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master

Scrum Master

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of “Done” as appropriate.

Sprint Planning Meeting

The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings.

A Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. This is an informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

sprint burndown

The sprint burndown chart is designed to help the team monitor its progress and be a leading indicator of whether it will meet its commitment at the end of the sprint. The classic format requires teams to estimate the duration of each task in hours and on a daily basis to chart the total remaining hours for all uncompleted tasks.

Sprint Goal
output from a Sprint Planning Meeting provides the Development Team with a target and overarching direction for the Sprint

iteration

An iteration is the full cycle of design-code-verify-release practiced by XP teams. It's a timebox that is usually one to three weeks long.

Iteration H is also referred to as Hardening Iteration.

Product Burndown Chart

A meta-view perspective of product development progress.

In Scrum, the product backlog is a "living document", available at all times during product development.

Release Plan

Teams are not required to have a release plan in Scrum, but they certainly have to plan the release.

The minimum plan necessary to start a Scrum project consists of a Vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.

Retrospective

A qualitative approach is also used in auditing the process, and this is referred to as the retrospective. A recognized exercise in the iteration retrospective is to engage the team in answering what went well in the iteration, what did not go well, and based on this information, what changes should be made going forward in the next iteration. Other retrospective activities may include conducting a root cause analysis, defining team working agreements, and recording decisions and identifying action items.

Explore

Explore phase plans and delivers running tested stories in a short iteration, constantly seeking to reduce the risk and uncertainty of the project

vision

The vision meeting is designed to present the big picture, get all team members on the same page, and ensure a clear understanding of what it is that they've been brought together to do. The vision defines the mission of the project team and the boundaries within which they will work to achieve the desired results. Here the scope is defined at a very high level.

Envision

In the Envision phase the team creates a preliminary feature or product breakdown structure in which features are identified In the Speculate phase, the team expands this list, and for each feature creates one or more "story" cards that contain basic descriptive and estimating information.

Envision determines the product vision and project objectives and constraints, the project community, and how the team will work together.

Speculate

Speculate phase develops a capability and/or feature-based release plan to deliver on the vision.

The product of the Speculate phase is a release plan based on capabilities or stories to be delivered rather than activities (as in traditional project plans).

Adapt

Adapt phase reviews the delivered results, the current situation, and the team's performance, and adapts as necessary.

Risks

Risks are identified in all planning meetings: release, iteration, and daily stand-ups

Risks can be analyzed and addressed in all planning meetings, with the focus on qualitative analysis, not quantitative.

Mitigate — Take steps before the risk materializes to reduce the eventual containment costs. For example, moving a feature to an earlier iteration to ensure that it's completed

Exposure --A specific amount of time or money used for the sole purpose of absorbing risk is called Risk Exposure.

PV

Present Value = Future Value/(1+R)n

Net Present Value (NPV) assumes reinvestment is made at the cost of capital.

Payback period

Payback period does not consider the time value of money and is therefore the least precise of all the cash flow analyses techniques.

CPI is a ratio that shows the current efficiency of money being spent on the project; the formula is EV/AC. A value of one means you are getting our what you put in (which is good); less than one is bad; greater than one is good.

The process of moving future amounts back into their present value is known as discounting. Clearly the interest rate that is used for discounting future amounts is critical to determining the present value of a future amount.

IRR assumes reinvestment at the IRR rate and it the discount rate when NPV is equal to zero.

Money earned

Money earned or spent today is worth more than money earned or spent in the future. In order to compare a current amount with a future amount, the future amount is discounted back into a current amount. The current amount is the amount that could be deposited in a bank or into some other relatively safe investment and that would grow to the future amount by the future time.