‭AGILE VALUES‬

‭ ‬ I‭ ndividuals and interactions‬‭over processes and tools‬

●
‭●‬ ‭Working software‬‭over comprehensive documentation‬‭(documentation should‬
‭be barely sufficient)‬
‭●‬ ‭Customer collaboration‬‭over contract negotiation‬
‭●‬ ‭Responding to change‬‭over following a plan.‬

‭12 AGILE PRINCIPLES‬

1‭ .‬ ‭ ustomer Satisfaction - our highest priority‬

C
‭2.‬ ‭Welcome Changes‬
‭3.‬ ‭Frequent Delivery‬
‭4.‬ ‭Collocated Team‬
‭5.‬ ‭Motivated Individuals‬
‭6.‬ ‭Face-to-face Conversation‬
‭7.‬ ‭Working Software‬
‭8.‬ ‭Constant Pace‬
‭9.‬ ‭Continuous Attention‬
‭10.‬ ‭Simplicity‬
‭11.‬ ‭Self-Organization‬
‭12.‬ ‭Regular Reflection‬

‭SCRUM‬

‭‬ V
● ‭ alues: Commitment, Courage, Focus, Openness, Respect‬
‭●‬ ‭3 Pillars‬
‭●‬ ‭Transparency‬
‭●‬ ‭Inspection‬
‭●‬ ‭Adaptation‬
‭●‬ ‭Product Owner (PO) is responsible for‬‭maximizing the‬‭value‬‭of the product and the‬
‭work of the team‬
‭●‬ ‭1 PO per team, but only 1 backlog for the whole product‬
‭●‬ ‭Responsible/accountable for‬‭backlog management‬
‭●‬ ‭The product owner represents the customer, users, and stakeholders. Take‬
‭risk into account when prioritizing backlog‬
‭●‬ ‭Development Team‬
‭●‬ ‭self-organizing, has all the skills needed, no titles, no sub-teams‬
‭●‬ ‭"share 2 pizzas" = team size between 3 and 9 (not counting PO and Scrum‬
‭Master). Other sources say the optimal team size is 8, others say 12.‬
‭●‬ ‭Scrum Master ensures the team understands and enacts Scrum‬
‭●‬ ‭humility, servant leader‬
‭●‬ ‭coaches the dev team and removes impediments‬
‭●‬ ‭​Team practices‬‭Sashimi‬‭to ensure every slice of functionality‬‭delivered is complete‬
‭EXTREME PROGRAMMING (XP)‬

‭‬ V
● ‭ alues: Simplicity, Communication, Feedback, Courage, Respect‬
‭●‬ ‭12 Practices‬
‭1.‬ ‭Pair Programming - one person codes—the‬‭driver‬‭. The‬‭other person is the‬
‭navigator‬‭, whose job is to think‬
‭2.‬ ‭Planning Game‬
‭3.‬ ‭Test Driven Development (TDD)‬
‭4.‬ ‭Whole Team - everyone sits together, generalized specialists‬
‭5.‬ ‭Continuous Integration‬
‭6.‬ ‭Refactoring‬
‭7.‬ ‭Small Releases‬
‭8.‬ ‭Sustainable Pace‬
‭9.‬ ‭Collective Code Ownership - multiple people work on all the code, any pair‬
‭of developers can improve or amend any code.‬
‭10.‬ ‭Coding Standard‬
‭11.‬ ‭Simple Design‬
‭12.‬ ‭System Metaphor‬
‭●‬ ‭Roles: Coach (= Scrum Master), Customer (= Product Owner), Developers, Testers‬
‭●‬ ‭Pair programming is the most helpful technique in implementing collective code‬
‭ownership in a team‬
‭●‬ ‭Code goes through 4 levels of completion: Broken, Build, Ready for demo, Ready to‬
‭release‬

‭LEAN‬

‭‬ L
● ‭ ean focuses on the‬‭Value Stream‬
‭●‬ ‭The 7 Lean principles:‬
‭●‬ ‭Eliminate waste‬
‭●‬ ‭Amplify learning (=early feedback loop)‬
‭●‬ ‭Decide Late (=defer as long as responsibly possible)‬
‭●‬ ‭Deliver Fast (=get value to the customer quickly)‬
‭●‬ ‭Empower the team‬
‭●‬ ‭Build integrity in (= test throughout, not just at the end)‬
‭●‬ ‭See the whole (=see the system not just the parts)‬
‭●‬ ‭Nonvalue-added time‬‭in Lean is the time in the cycle‬‭where we find delays, waste‬
‭and constraints.‬
‭●‬ ‭Examples of Waste‬
‭●‬ ‭Partially done work (e.g. untested code)‬
‭●‬ ‭Extra processes (e.g. approval from manager who is not a true stakeholder)‬
‭●‬ ‭Extra features (gold plating)‬
‭●‬ ‭Task switching (e.g. if you're assigned to multiple projects)‬
‭●‬ ‭Waiting (e.g. waiting on sign-offs)‬
‭●‬ ‭Motion (e.g. poor communication between teams)‬
‭●‬ ‭Defects‬
‭KANBAN‬

‭‬ A
● ‭ key tool in lean manufacturing‬
‭●‬ ‭Focused sustainable pace and regular JIT delivery of individual items. Optimize the‬
‭flow.‬
‭●‬ ‭Core Practices‬
‭●‬ ‭Define and visualize the workflow‬
‭●‬ ‭Limit Work-In-Progress (WIP)‬
‭●‬ ‭Measure and Manage Flow‬
‭●‬ ‭Make Process Policies Explicit‬
‭●‬ ‭Use Models to Suggest Improvement‬
‭●‬ ‭In practice, start by 1) visualizing the flow of work to identify bottlenecks, 2) speed‬
‭up or remove the bottlenecks that affect overall throughput 3) establish WIP limits,‬
‭and then 4) look for continuous improvement.‬
‭●‬ ‭Compared to Agile, Kanban focuses on‬‭continuous flow‬‭(vs. fixed iterations) and‬
‭cycle time‬‭(vs. velocity)‬
‭●‬ ‭Cycle time = # completed items/# days‬‭, the average‬‭time between the delivery of‬
‭completed work items. For example 10 completed items in 5 days means a cycle‬
‭time of 0.5 days/item.‬
‭●‬ ‭Task Board‬‭serves the dual purpose of giving the team‬‭a convenient mechanism‬
‭for organizing their work and a way of seeing at a glance how much work is left.‬
‭Can be a whiteboard, cork board, cardboard, etc.‬
‭●‬ ‭Lets you visualize the workflow and identify constraints.‬
‭●‬ ‭On a task board you have‬‭3 basic columns: to-do,‬‭in-progress, done‬‭.‬
‭●‬ ‭The‬‭WIP number‬‭on the board is the max number of work‬‭items in a swim‬
‭lane.‬
‭●‬ ‭Kanban board uses a‬‭pull system‬
‭●‬ ‭Little's Law: # of items in the system = Rate items enter the system x Average‬
‭time items spend in the system.‬‭Demonstrates that‬‭the duration of work queue is‬
‭dependent on its size. Following Little's Law, to improve cycle time,‬‭reduce WIP‬
‭(work in progress) and‬‭increase ACR‬‭(average completion‬‭rate).‬
‭●‬ ‭Throughput‬‭is the number of features the team can‬‭develop in a particular‬
‭amount of time.‬
‭●‬ ‭A testing team finds that it is often in the firing line as they often have more work‬
‭than they can handle. In the Kanban system the best way to handle this is to limit‬
‭the WIP. This will address the feeling of being overwhelmed with work and pave‬
‭the way for more creative solutions to the problem.‬
‭●‬ ‭David Anderson 5'S for Kanban agile development: Set in order, Sort, Shine,‬
‭Standardize, Sustain‬
‭●‬ ‭Scrumban‬‭is a hybrid of Scrum and Kanban‬
‭PLANNING TECHNIQUES‬

‭●‬ I‭ n agile you will spend more time planning overall than in waterfall! However the‬
‭planning is spread out over the course of the project.‬
‭●‬ ‭Vision and requirements gathering‬‭:‬
‭●‬ ‭Design the Box -‬‭break into small groups and design‬‭the product name,‬
‭graphic, elevator pitch on the front, detailed features on the back, and‬
‭operating instructions‬
‭●‬ ‭Prune the Tree‬‭- a requirements gathering technique‬
‭●‬ ‭Remember the Future‬
‭●‬ ‭Prioritization‬‭:‬
‭●‬ ‭MoSCoW‬
‭●‬ ‭Must Have – Critical to the current delivery timebox in order for it to‬
‭be a success‬
‭●‬ ‭Should Have – important but not necessary for delivery‬
‭●‬ ‭Could Have – Desirable, but not necessary; Could improve user‬
‭experience or customer satisfaction for very little cost‬
‭●‬ ‭Won’t Have – Have been agreed by stakeholders as the least-critical‬
‭and not to be delivered in the current timebox‬
‭●‬ ‭MustHave+ShouldHave = business case. Must+Should+Could =‬
‭business case + contingency, 100% of total.‬
‭●‬ ‭Kano Analysis‬‭:‬
‭●‬ ‭Exciters/Delighters‬‭– features deliver unexpected‬‭benefits to the‬
‭customer‬
‭●‬ ‭Performance/Satisfiers/Threshold/Must-Have‬‭– features‬‭deliver‬
‭expected benefits to the customer‬
‭●‬ ‭Basic/Dissatisfiers‬‭– If these features are missing,‬‭customers will be‬
‭unhappy‬
‭●‬ ‭Indifferent‬‭– Customers do not care if these features‬‭are in the‬
‭product or not‬
‭●‬ ‭Performance – Linear relationship between‬
‭functionality/quality and customer satisfaction‬
‭●‬ ‭Excitement – Customers will be willing to pay premium for‬
‭these features, lack of features will not decrease satisfaction‬
‭●‬ ‭Basic – Making these better, will not improve customer‬
‭satisfaction, best is neutral • Indifferent – Minimize these‬
‭features inclusion‬
‭●‬ ‭Basic/Dissatisfiers are most important compared to‬
‭Delighters or Satisfiers. This will cause the customer to dislike‬
‭a product if they are not present. Indifferent features should‬
‭be minimized or eliminated.‬
‭●‬ ‭Relative Weighting‬‭-‬‭priority of a feature is determined‬‭by dividing the‬
‭priority % by the cost %‬
‭●‬ ‭Bang for the Buck‬‭,‬‭Buy a Feature, 100 Point Method‬
‭●‬ ‭Estimation‬
‭●‬ ‭Affinity estimating‬‭(e.g. T-Shirt sizing)‬‭is the practice‬‭of using common‬
‭sizes to rapidly place user stories into similarly sized groups - good for when‬
‭you have at least 20 stories, ideally 40 stories or even 100s of stories. Each‬
 s‭ tory is placed on a table and one by one a team member is given an‬
‭opportunity to place a card in line or adjusting a card in the line already.‬
‭●‬ ‭Wideband Delphi‬‭(e.g. Planning Poker)‬‭estimation includes‬‭plotting‬
‭estimates on a chart with no names, and then the range of points is‬
‭discussed, and the team attempts to reach a general consensus. Wideband‬
‭Delphi is anonymous estimates which minimizes the Bandwagon effect,‬
‭HIPPO decision making and Groupthink‬
‭●‬ ‭Decision making‬‭:‬‭Fist to five‬‭,‬‭thumbs up‬‭, thumbs down‬‭or thumbs sideways, and‬
‭decision spectrum,‬‭Dot Voting‬‭(stickies),‬‭Forced Ranking‬‭(score criteria, then‬
‭rank in order based on score)‬
‭●‬ ‭Buy a story‬‭is a collaboration game to help stakeholders‬‭understand a complex‬
‭issue‬
‭‬
● ‭Brainstorming‬‭:‬‭Round robin‬‭,‬‭Quiet Writing‬‭,‬‭Free for‬‭all‬‭.‬
‭●‬ ‭Collaboration:‬‭Listening Game‬‭,‬‭Collaborative Origami,‬‭123 Go‬

‭AGILE CHARTER AND PROGRAM‬

‭●‬ ‭Agile charters‬‭answer the W5H questions (who? what?‬‭where? when? how?)‬
‭●‬ ‭Charter doesn't specify costs or specific team members‬
‭●‬ ‭If the charter doesn't exist, create one with the sponsor‬
‭●‬ ‭5 Phases of Agile Project Management: Envision, Speculate (including release plan‬
‭and stories), Explore, Adapt, Close‬
‭●‬ ‭Planning Onion‬‭: Strategy, Portfolio, Product, Release,‬‭Iteration, Day. Team is mainly‬
‭involved starting at Release.‬
‭●‬ ‭4 types of revenue‬
‭●‬ ‭​New revenue (from new markets, customers, features)‬
‭●‬ ‭Incremental revenue (existing features are enhanced, add-on's, encourage‬
‭customer to buy more)‬
‭●‬ ‭Retained revenue (what you will lose if you don't develop key features, could‬
‭relate to regulatory)‬
‭●‬ ‭​Operational Efficiences (internal improvement)‬
‭BACKLOG, EPICS, USER STORIES‬

‭●‬ U ‭ ser stories are not the same as "use cases" or "design scenarios". They are‬‭support‬
‭tools for analysis‬‭.‬
‭●‬ ‭User stories should be written following‬‭INVEST‬‭principles:‬
‭●‬ ‭​I: Independent‬
‭●‬ ‭N: Negotiable‬
‭●‬ ‭V: Valuable‬
‭●‬ ‭E: Estimable‬
‭●‬ ‭S: Specific (or Small)‬
‭●‬ ‭T: Timely (or Testable)‬
‭●‬ ‭Each story has 3 elements, the‬‭3 C's‬
‭●‬ ‭the Card (the story should fit on a 3" x 5" card)‬
‭●‬ ‭the Conversation (user stories are communicated by end-users to‬
‭developers)‬
‭●‬ ‭the Confirmation (the acceptance criteria)‬‭​‬
‭●‬ ‭A‬‭story map‬‭is like a product roadmap, using future‬‭stories to be implemented.‬
‭Story mapping‬‭is used to identify missing stories,‬‭categorize stories into‬
‭functionality and prioritize stories.‬
‭●‬ ‭Epic stories‬‭are large stories that have not been‬‭broken down, and these are‬
‭typically found at or near the bottom of the product backlog.‬
‭●‬ ‭Disaggregation‬‭refers to splitting a story or feature‬‭into smaller, easier-to-estimate‬
‭pieces (NOT decomposition)‬
‭●‬ ‭Small stories‬‭such as cosmetic UI changes and reading/writing‬‭bug reports can be‬
‭combined into larger stories‬
‭●‬ ‭Spikes‬‭: architectural spike (e.g. proof of concept),‬‭risk-based spike‬
‭●‬ ‭Research stories‬‭should last 1 day‬
‭●‬ ‭Acceptance criteria‬‭come from the‬‭customer‬‭, even if‬‭ultimately a team member‬
‭might be the one to write them down‬
‭●‬ ‭Theme‬‭is a set of related user stories that may be‬‭combined together and treated‬
‭as a single entity for either estimating or release planning.‬
‭●‬ ‭Quantity of function‬‭is scope measured in terms of‬‭user stories, use cases,‬
‭requirements, or features‬
‭●‬ ‭The‬‭risk-adjusted backlog‬‭is a primary way in which‬‭risk is managed. Stories in a‬
‭risk-adjusted backlog are‬‭prioritized based on EMV‬‭(expected monetary value).‬
‭●‬ ‭Grooming the backlog = refinement = adding detail, add/remove stories,‬
‭prioritize‬
‭RELEASE PLANNING, ITERATION PLANNING and STAND-UPS‬

‭●‬ ‭When‬‭release planning‬‭:‬

‭●‬ ‭slice stores‬
‭●‬ ‭estimate velocity‬
‭●‬ ‭select stories‬
‭●‬ ‭Waves/milestones‬‭are intermediate 1-3 month timeframes‬‭with story-level‬
‭capability and commitment. When a milestone is achieved, someone can verbally‬
‭announce it ("declaration milestone")‬
‭●‬ ‭Definition of ready‬‭determines when an item is ready‬‭for development (ie. when it‬
‭can go into an iteration)‬
‭●‬ ‭Staging‬‭is the process of defining and prioritizing‬‭the nonfunctional requirements.‬
‭Occurs prior to the start of the first Sprint and takes just one day.‬
‭●‬ ‭Iteration planning includes the defining of tasks on an agile project.‬‭Break stories‬
‭into tasks during iteration planning‬
‭●‬ ‭Tasks are self-assigned‬‭by the team. If no one wants‬‭a task, the team collectively‬
‭decides. Task assignments are done by the team in a self-organized agile team‬
‭●‬ ‭Tasks are estimated at the time of Iteration Planning as well as during the iteration‬
‭●‬ ‭The PO shouldn't attend the standup which is a meeting of, for, and by the team‬
‭●‬ ‭End of iteration demo is called a‬‭product review meeting‬

‭AGILE PROJECT SCHEDULE‬

‭●‬ T ‭ he agile project schedule is created by estimating story points and applying‬
‭velocity.‬
‭●‬ ‭Sprint 0‬‭(or 'Iteration 0') does not deliver customer‬‭value. It can include initial‬
‭training.‬
‭●‬ ‭Actual time‬‭is the amount of time an assignment would‬‭take to complete.‬‭Ideal‬
‭time‬‭is the amount of time an assignment would take‬‭if there were no‬
‭interruptions or distractions. The conversion to‬‭elapsed‬‭time‬‭depends upon‬
‭individuals involved but can usually be reasonably estimated at an aggregate or‬
‭team level.‬
‭●‬ ‭If project is‬‭release-timeboxed‬‭, a team can maintain‬‭a feature buffer and follow a‬
‭MoSCoW scheme to logically sequence the work.‬
‭●‬ ‭To avoid bottlenecks, it is recommended to get the team to be generalists so‬
‭anyone can pick up any task.‬
‭●‬ ‭Biggest advantage to delivering‬‭incrementally‬‭is that‬‭it‬‭reduces the amount of‬
‭rework‬‭by finding issues earlier.‬
‭●‬ ‭Velocity‬‭= number of story points a team can complete‬‭in a single iteration‬
‭●‬ ‭A team's‬‭velocity‬‭is not likely to be comparable to‬‭another one, so using industry‬
‭standards or using velocity to compare to teams is meaningless. Calculate velocity‬
‭in the early sprints by team consensus or using team capacity. Compare teams by‬
‭ROI, not by velocity.‬
‭●‬ ‭The team should get to‬‭predictable‬‭velocity‬
‭●‬ ‭Lead time‬‭is the amount of time needed to get a feature‬‭from inception to live‬
‭deployment (not velocity)‬
‭●‬ ‭Feeding buffer‬‭is applied to stories that depend on‬‭other stories, in case the‬
‭dependencies are late‬
‭RETROSPECTIVES‬

‭●‬ ‭Format of meeting (15-60min):‬

‭●‬ ‭Set the stage‬
‭●‬ ‭Problem solving: gather data, generate insights, decide what to do‬
‭●‬ ‭Closing‬
‭●‬ ‭Set the stage‬
‭●‬ ‭Everyone sits in circle or semi-circle‬
‭●‬ ‭Techniques:‬‭Check In, Focus On/Off, ESVP‬‭and‬‭Working‬‭Agreements‬‭.‬
‭●‬ ‭ESVP‬‭is a technique used to anonymously identify team‬‭members'‬
‭attitudes towards retrospectives as: Explorers, Shoppers, Vacationers,‬
‭Prisoners.‬
‭●‬ ‭Generate insight techniques:‬‭Brainstorming, Pair‬‭Interviews‬
‭●‬ ‭Force field analysis‬‭= analyzing factors that drive‬‭change and restrict change‬
‭●‬ ‭Decide what to do techniques:‬‭Short Subjects‬‭,‬‭Triple‬‭Nickels, Voting with Dots‬
‭●‬ ‭Closing ​techniques:‬‭Plus/Delta‬‭or‬‭Speedboat‬‭to ask‬‭what team want more/less in‬
‭next iteration regarding process.‬
‭●‬ ‭ARCS‬‭, criteria for evaluating Instructional designs:‬
‭●‬ ‭Choose activities that help people stay engaged so they don’t drift off‬
‭(Attention)‬
‭●‬ ‭That are relevant to the goal (Relevance).‬
‭●‬ ‭You want activities that people can accomplish successfully‬
‭(Confident/Competence).‬
‭●‬ ‭Finally, make sure activities fit into the overall design so people think the‬
‭retrospective is a good use of their time (Satisfaction).‬
‭●‬ ‭Return on Invested Time (‬‭ROTI‬‭) is used to determine‬‭the quality of the‬
‭retrospective.‬
‭●‬ ‭You have Release Retrospectives, Project Retrospectives, Iteration Retrospectives‬
‭and Surprise Retrospectives. Surprise Retrospective is conducted when an‬
‭unexpected event changes your situation.‬

‭AGILE MODELING‬

‭●‬ ‭Agile modelling techniques are:‬

‭●‬ ‭use cases‬
‭●‬ ‭data diagram‬
‭●‬ ‭screen designs‬

‭DEVOPS‬

‭●‬ D ‭ evOps helps speed up the deployment of products from development to‬
‭operations‬
‭●‬ ‭Continuous integration‬‭(CI) is executed when code‬‭changes are checked in and‬
‭tested daily. CI c‬‭omponents include source code control‬‭system, build tools, test‬
‭tools, scheduler/trigger, notifications BUT NOT UNIT TESTS‬
‭AGILE CONTRACTS‬

‭●‬ I‭ f schedule variance is expected, use graduated fixed price contracts (when both‬
‭parties share some of the risk and reward associated with schedule variance)‬
‭●‬ ‭A DSDM Contract focuses on work being "fit for business purpose"‬
‭●‬ ‭"Money for nothing" in Agile contracting created by Jeff Sutherland means‬
‭customer can terminate early‬

‭INFORMATION RADIATORS, KPIs‬

‭●‬ I‭ nformation radiators include: burn charts, retrospective learnings, story maps (but‬
‭not the definition of done)‬
‭●‬ ‭Some stakeholders may want a‬‭vision statement‬‭. Next‬‭most detailed is the‬
‭roadmap‬‭. Then the detailed‬‭release plans‬‭and‬‭iteration‬‭plans‬‭.‬
‭●‬ ‭The‬‭burnup chart‬‭plots time on the X-axis and functionality‬‭on the Y-axis.‬
‭●‬ ‭Get a bird’s-eye view of the project.‬
‭●‬ ‭Shows progress and predicts a completion date.‬
‭●‬ ‭Burnup charts can show the impact of‬‭scope changes‬‭.‬‭Usually product‬
‭when you‬‭update the‬‭release plan‬‭.‬
‭●‬ ‭The‬‭burndown‬‭charts‬‭are used to track scope and schedule‬‭progress of the‬
‭project. A cumulative story point burndown chart is useful because it shows the‬
‭total number of story points completed through the end of each iteration.‬
‭●‬ ‭Example in practice:‬‭s‬‭tart at 200 points, the team‬‭completes 50, the PO‬
‭adds 20 more. As 20 points get added, the bottom of the bar shifts down by‬
‭20 points and reads "-20". The top of the bar moves down as the team‬
‭completes the work. As 50 points are completed, the top will be at 150.‬
‭●‬ ‭4 KPIs‬‭used in Agile are‬
‭●‬ ‭remaining work‬
‭●‬ ‭rate of progress‬
‭●‬ ‭likely completion date‬
‭●‬ ‭likely costs remaining‬
‭●‬ ‭Best metric to compare agile teams‬‭:‬‭ROI, not velocity‬
‭●‬ ‭A‬‭S-curve‬‭is a graph that tracks a variable over time.‬
‭●‬ ‭EMV chart‬‭is a‬‭leading‬‭indicator which is why it is‬‭better than a GANTT chart.‬
‭●‬ ‭Trend analysis‬‭is a lead metric as it helps forecast‬‭issues based on trends.‬

‭QUALITY‬

‭●‬ A ‭ n‬‭escaped defect‬‭is a defect that wasn’t discovered‬‭by test teams. Instead, the‬
‭defect was found by customers.‬
‭●‬ ‭Component tests‬‭(as opposed to unit tests) verify‬‭that units and combinations of‬
‭units work together‬
‭●‬ ‭Error-feedback ratio‬‭is the number of new defects‬‭injected when fixing existing‬
‭defects (e.g., 20 new defects generated in fixing 100 defects would be an‬
‭error-feedback ratio of 20%)‬
‭●‬ ‭Capers Jones concluded "a‬‭cumulative defect removal‬‭rate of 95%‬‭on a project‬
‭appears to be a nodal point where several other benefits accrue"‬
‭PMP FINANCIAL FUNDAMENTALS, APPLIED TO AGILE‬

‭●‬ N ‭ et Present Value (NPV)‬‭• The present value of the‬‭cash flows, at the required rate‬
‭of return of your project, compared to your initial investment‬
‭●‬ ‭To compare projects, use NPV. The higher NPV the better.‬
‭●‬ ‭Time value of money‬
‭●‬ ‭A positive NPV means the project is profitable, a Negative NPV means the‬
‭project is not profitable‬
‭●‬ ‭Drawbacks – Need to make assumptions are inflation and interest rates‬
‭●‬ ‭Internal Rate of Return (IRR)‬‭• The discount rate‬‭that makes the NPV of all cash‬
‭flows equal to zero • Removes the assumptions of interest and inflation rates •‬
‭Complicated to calculate, expressed as a %. When comparing projects, chose the‬
‭project with the higher IRR.‬
‭●‬ ‭Note that IRR is a superior measure to NPV, and should be used for making‬
‭decisions in benefit-cost analysis.‬
‭●‬ ‭ROI‬‭= Benefits/Investment‬‭. Higher is better. Example‬‭• Feature costs – $100,000,‬
‭Net Profit (i.e. benefits)- $25,000, therefore ROI = 25% • Drawback – Revenue‬
‭generated after the period of time, time value of money.‬
‭●‬ ‭The‬‭payback period‬‭is a calculation where a shorter‬‭payback period is preferred‬
‭over a larger period.‬

‭OTHER PMP FUNDAMENTALS‬

‭●‬ E ‭ arned value management (EVM)‬‭in an agile project‬‭should be measured at the‬

‭iteration level,‬‭because this is the level where velocity‬‭is measured and resources‬
‭are applied.‬
‭●‬ ‭Kaizen‬‭is the term for making small changes. The‬‭Plan-Do-Check-Act‬‭(PDCA)‬‭is‬
‭the cycle developed by Edward Deming for implementing small improvements.‬
‭●‬ ‭Common causes vs. special causes.‬‭Too often common‬‭causes are mistaken for‬
‭special causes. If it's a common cause, do nothing.‬
‭LEARNING‬

‭●‬ W ‭ hen a team is trying to learn agile, First they need to "think", meaning‬
‭individually learning and internalizing agile principles (think first, then do).‬
‭●‬ ‭In Agile,‬‭you can change the plan when something new‬‭is learned‬‭or when it is‬
‭known that a mistake is to be avoided. You don't have to wait for the end of the‬
‭iteration.‬
‭●‬ ‭The‬‭3 Agile coaching styles‬‭are‬‭Training/Teaching,‬‭Coaching and‬
‭Mentoring/Advising‬‭(not supporting). When the team‬‭is storming, you should‬
‭coach with a focus on conflict resolution.‬
‭●‬ ‭Listening types: 1. internal 2. focused 3. global‬
‭●‬ ‭Shu Ha Ri‬‭. Shu: Follow the rule. Ha: Break the rule.‬‭Ri: Be the rule.‬
‭●‬ ‭For looking at how a team can improve, there are 3 levels‬
‭●‬ ‭The process level: How are we doing with agile?‬
‭●‬ ‭The quality and performance angle: How can the team produce better?‬
‭●‬ ‭The team dynamics dimension: How can the team become a better team?‬
‭●‬ ‭Lyssa Adkins guidelines for one-on-one coaching are guarantee safety, meet them‬
‭a half-step ahead, partner with managers and create positive regard‬

‭TEAM BUILDING AND COMMUNICATION‬

‭‬ S
● ‭ ervant leadership‬‭: shield the team, remove impediments,‬‭carry food and water‬
‭●‬ ‭Caves and common area‬‭are essential for a team space‬‭so the team have caves‬
‭where they can work in quiet and a common area where knowledge sharing can‬
‭happen‬
‭●‬ ‭Decision framing‬‭focuses on who gets involved in the‬‭decision process. Who‬
‭makes the decision is less important than getting the right people involved in the‬
‭decision process.‬
‭●‬ ‭Health checks‬‭, often questionnaires, help determine‬‭how well the team is‬
‭adhering to Agile process.‬
‭●‬ ‭When facilitating meetings the facilitator is responsible for the goals, rules, timing,‬
‭assisting, including meeting minutes‬
‭●‬ ‭During problem solving, ask questions and listen, but avoid injecting your own‬
‭ideas‬
‭●‬ ‭After understanding ones own feelings next is to manage them and then become‬
‭more aware of others and finally they will be able to influence others feelings.‬
‭●‬ ‭The 5 dysfunctions of a team are Absence of Trust, Fear of Conflict, Inattention to‬
‭Results, Avoidance of Accountability, Lack of Commitment‬
‭●‬ ‭Level-based conflict. It's best to empower the team members to solve conflict‬
‭themselves (e.g. Level 2 conflicts), unless the temperature is really high‬
‭●‬ ‭For announcing sprint priorities, two-way communication model ensures‬
‭information is bidirectional.‬