Agile

Question 1

What is the purpose for a User Story format?

What is the format of a US?

Answer 1

To capture a requireement or feature from perspective of end user which has to meet acceptance Criteria conditions to ensure they are implemented correctly.

US is a description of the feature from users perspective:

Format
1st part: Description: as a [user], I want [functionality], so that [Benefit]..
2nd part: Acc.Crit
* TDD acc.Crit: Crit1 Condition, Crit 2 Cond,. ..
* BDD Acc.Crit: Given, When, Then(easier to understand by everyone)

US derived from broader requirements and include acceptance criteria

BDD: Uses behaviors instead of strict condition

Question 2

11 insert image

What is SAFe(Scaled Agile Frameworks)?

Answer 2

Detailed and Structured approach to agile framework, more governance and rigid than regular agile. Focuses org project teams on value streams(prods/Servs) that provide valute to customer
* New Roles: Requires additional roles for more rigid coordination and governance compared to Scrum of Scrum and LeSS including Release Train Engineer, Solution Train Engineer, and Epic Owners
* Team Coordination:
* Agile Release Train: Teams of Agile Teams that plan, commit and execute together to deliver value in a program increment.
* Program Increment(PI) Planning: Regular, large scale planning events that align all team on goals and dependencies.
* Enterprise Alignment: Focuses on aligning strategy and execution w/ strong governance and compliance mechanisms
* Alignment: Ensure alignment of strategy and execution across all levels of the org.
Gov and Compliances: Provides mechanisms for governance, compliance, and metrics.

Question 3

What are the 3 Scaled Frameworks in Agile?

Answer 3

• Scrum of Scrums(SoS): For org that needs a simple coordination mechanism.
• Large Scale Scrum(LeSS): For those looking for minimalist approach that stays close to scrum principles.
• Scaled Agile Frameworks(SAFe): For large enterprise requiring a comprehensive and structured scaling solution.

Question 4

What is Scrum of Scrums?

Answer 4

Coordination method of multiple scrum teams w/out adding new roles.

Decentralized Coordination:
* SoS meetings: Reps(SM) from each team meet regularly to discuss progress, dependencies, and impediments.
* Portfolio Scrum Team(Scrum of Scrums of Scrums) has Rep from each Program scrum team(SM)
- Program Scrum of Scrums: Has rep from each project team(SM)
- Project Level: Each project has regular scrum team
- Scrum Teams from Project level->Program Level to Portfolio level.

Question 5

10 Insert image

What is Large Scale Scrum(LeSS)?

Answer 5

Simplifying org structure by remaining flexible and adaptable.
* Simplicity & Minimalism: Focus on simple and extending basic scrum principles.
* One PO: Responsible for vision and direction, scrum feature teams
* One PBL
* One DoD
* Feature Teams: Focus on 1 feature and has their own SM.
* Teams plan their own sprints, while collaborating and communicating w/ other teams. To deliver PBL items.
* PBL Refinement: Mid Sprint
* Sprint Review and Retrospectives

Question 6

Procurement

What does agile procurements aim for?

Answer 6

Agile favors customer collaboration over contract negotiations
Agile Procurements aims for a collaborative approach that pursues a shared risk-reward relationship

EXs: Multi Tiered Structure, Emphasize Value Delivered(milestones), fixe

Question 7

slide 9 insert image

What is the collecting requirements process in agile?

Answer 7

Product Vision and Roadmap:
Prod Vision: Define overall product vision and goal
Roadmap: Create high level product roadmap outlining major features and releases.
Backlog Creation and Refinement
User Stories and Epics: Breakdown high level reqs into US’s and epics.
Backlog Grooming/Refinement: Regularly to refine and prioritize Uss.
Engage SHs regularly to ensure backlog refelcts current needs and priorities
User Story Mapping: Visual tech to map out the user jouney and ID all necessary features.
Helps in understanding the scope and sequence of development.
Workshop and Interviews: Collaborative discussions w/ SHs to gather detailed requirements.
Continuous feedback loop.
Prototype and Feedback: Build and show prototype or wireframes to validate ideas and get feedback.
Iterative approach to refining requirements based on user feedback.

Question 8

Insert image slide 9

What are project Initiation steps in agile?

Answer 8

1. Project Charter: Focuses on vision and goals, less detailed than predictive Proj Charter.
   * High level doc outlines proj purpose, objectives, key SHs, initial constraints.

2.Initial Planning:
* Sprint Zero: Team spend short initial period(a sprint or part of a sprint) setting up the project environment, tools, processes.
* Establish initial PBL
* Define Teams working agreements(What is DoR and DoD)

3.SH Engagement: ID key stakeholders, establish comm channels.
* Understand SH expectations and needs.
* Continuous engagement throughout project lifecycle.

Question 9

What are the Agile Procurement Contract Types Multi Tiered Structure and Emphasized Value Delivered?

Answer 9

Multi-Tiered Structure: Describe different agreements in different documents. Where we may have different ways of working in different documents.
* Ex: may have majority of project work done in predictive way of work.
Then in Appendix may have Agile way of working for just a portion of the system.

Emphasize Valude Delivered: : Milestones and payment terms can be structured based on value driven deliverables.
* Ex: If 3rd party delivering those features, we can structure payment terms around delivering those features.

Question 10

What are the Agile Procurement Contract Types Fixed Price Increments and Not-To-Exceed T&M?

Answer 10

Fixed Price Increments: Decompose the scope into fixed price micro-deliverables, even down to the story. This gives more control over how money spent.
* If we have Backlog of work, can put price on each feature(Increment)

Not-To-Exceed T&M: An alternative to Time and Materials where the cost may exceed budget, this limits overall budget to a fixed amount.
* When customer want to incorporate new ideas, they prioritize- managing the given capacity and replacing original work w/ new work.
* Replacing original features in PBL w/ new Items, so we’re not just stacking it to the list.
* In agile we know we have fixed cost and time.

Question 11

What are the Agile Procurement Contract Types Graduated T&M and Early Cancellation?

Answer 11

Graduated T&M: As long as quality criteria is part of what “Done” means, the supplier can be awarded w/ a higher hourly rate when delivery is earlier than the contract deadline.
* As long as quality is good and apart of DOD, and vnd deliver earlier than deadline, he gets more pay.(Usually faster means poor quality, but if qlty good gets reward.)

Early Cancellation option: When supplier delivers sufficient value w/ only half the scope completed, they should not be obligated to pay the remaining half if customer no longer needs it.

Question 12

What are the Agile Procurement Contract Types Dynamic Scope Option and Bring the External Party into Team?

Answer 12

Dynamic Scope Option: On contracts w/ a fixed budget, the supplier may offer the customer the option to vary the scope – to adjust features to fit the capacity.
* Then the customer can leverage new innovations while limiting the suppliers risk of over-commitment.
* Aka we’re paying them for fixed amt of time, then we can just change the scope, to fit that certain amt of time. Limits supplier overcommitment risk.

Bring the External Party into the Team: W/ the WHOLE TEAM APPRAOCH, the most collaborative contracting approach is to embed the supps services directly into the customer org, funding stable teams instead of specific scope.

Favor full service suppliers: The more suppliers, the more dependencies

Question 13

What are the 3 types of Impediments to agile team?

Answer 13

Impediments: Anything that slows down or hinders progress of team but doesn’t completely stop work.
* can be resolved with some level planning(daily stand up issue work on issue)
* Ex: A lack of a required tool, insufficient documentation, or a minor disagreement among team members.
Situations, conditions and actions that slow down or hinder progress, causing delays.
* Ex: Like driving through rough terrain, slows you down towards reaching goal.
* Example: A team member is sick for a few days, slowing down progress, but the team can rearrange tasks to manage it.
* Team member not trained properly to assigned job. lack of training takes longer

Obstacles: General term that can encompass anything(Barrier) that impedes, delays, or blocks progress.
* Barriers that should be able to be avoided or overcome with some strategy or effort.
* Barriers that might not always slow progress but can make tasks more laborious.
* Like driving through road with objects in the way, an have to take a narrow path between objects to reach goal
* Ex: Team can’t access sw due to delay in approval of purchase of sw license.
* Ex: temporary power outage at the work site prevents team members from doing their job.
* Ex: Team member in accident and out of office 1 month.

Blockers: Specific issues that completely stop the team’s progress on a particular task or user story until they are resolved.
* Usually caused by external factors(outside team or org), that needs external intervention(SH, external team) to resolve
* Completely stops project progress, impossible to continue working until resolved.
* Example: A legal or regulatory change outside of the team’s control that requires a new approval process before work can continue.
* A sole supplier of services suddenly goes out of business brining the project to halt.

Question 14

What is an Impediment?

Answer 14

Impediments: Anything that slows down progress of team but doesn’t completely stop work.
AKA a BLOCKER
Scope: Generally broader, including minor and major issues that hinder progress
Ex: A lack of a required tool, insufficient documentation, or a minor disagreement among team members.
Situations, conditions and actions that slow down or hinder progress, causing delays.
Ex: Like driving through rough terrain, slows you down towards reaching goal.

Question 15

What is an Obstacle?

Answer 15

Obstacles: General term that can encompass anything that impedes, delays, or blocks progress.
Scope: Can be used interchangeably with impediments and blockers but is less specific.
Ex: Can include both impediments and blockers, such as a cumbersome process, a lack of stakeholder support, or technical difficulties.
Barriers that should be able to be avoided or overcome with some strategy or effort.
Barriers that might not always slow progress but can make tasks more laborious.
Like driving through road with objects in the way, an have to take a narrow path between objects to reach goal

Question 16

What is a Blocker?

Answer 16

Blockers: Specific issues that completely stop the team’s progress on a particular task or user story until they are resolved.
Scope: Usually more urgent and severe than impediments, requiring immediate attention.
Ex: Waiting for a critical decision from management, a key team member being unavailable, or a technical dependency that hasn’t been resolved.
Events or conditions that cause stoppages in the work or advancement.
Factors that entirely halt progress.

Question 17

How is Risk Managed in Agile using all the steps in risk management?
1. Plan Risk Management
2. ID Risks
3. Qual Analysis
4. Quant Analysis
5. Plan Risk Responses
6. Implement Risk Respsonses
7. Monitor Risks
8. Repeat from 2.

Answer 17

Done same time as other agile tasks.

Discover Risks through Retrospectives and Standups
* Retrospectives: We ask and take action(Create Risk Card) for:
-What went well? What Challenges us? What did we Learn? What still puzzles us?
* Stand-ups: Every day meet and raise Blockers(Raise Risk Card) so we can swarm around and fix them.

Manage Risks through Risk Adjusted Backlog
* Risks, with their probability and Impact(qualitative), are added as User Stories to the backlog and prioritized against the value of normal tasks.
-Risk US: Prob(%)/Impact($)
-Added to PBL
-Prioritized(Risk of $1M) against other PBL US/Features(Value$).

Identify Risks(171): Identifying risks is done organically on an Agile project, through it’s natural way of working and ceremonies
* Visual Management: Info Radiators- Can see if we’re behind or ahead of schedule or if things aren’t flowing, or if things are blocked.
-Kanban Board, Burndown Chart, Risk Register, PBL, and Roadmap.
-All visible so anyone can see how we are tracking at anytime.
* Retrospectives and Stand ups

Agile-Qualitative Risk Anl(172): Still want to analyze risks we find in Agile project.
* We can add Likelihood and Impact ratings to the Risk Stories we place in our Backlog
-To help us prioritize them against value-added US.
* Risks: Hold Risk Workshops, or raise risks from stand-ups or Retrospectives
* Backlog: Add them as a Risk US to the PBL, w/ their Prob(%)/Impact($) info.
* Prioritized: Prioritize the negative risk impact or risks, vs the positive value added by the US/feature

Quantitative Risk Analysis(173): No Version in Agile, just predictive.
* Agile only goes up to Qualitative

Plan Risk Responses(174): Risk responses have many places in agile. Where possible want to raise and solve risk close to when and where it happens.
* Retrospectives: Ensure we take actions(w/ owners) for anything that challenges us during a sprint. If risk raised to in Risk adjusted PBL, so always visible and can be prioritized against other normal US’s.
* Stand-Ups:When blockers are raised during stand ups, we want to solve them close in person, place, and time.
-Pairing: Working in pairs to complete, check and learn together.
-Swarming: If an Issue. Multiple members getting around a problem to solve it quickly.(Not during stand up but directly after.)
-Mobbing: Teams work closely together around a core outcome.
* Risk Adjusted Backlog: Risks are prioritized, just like normal proj, except risk cards are prioritized against user stories in the PBL.

Monitor Risks(196): Just like quality, risk is everyone’s responsibility on agile project.
* We can still hold separate risk review session if we want, but risks are made visible and are managed through PBL, like everything else.
* Risk Adjusted BL: Risks are raised as US, with their Prob(%)/Impact($) ratings. Prioritize them against the normal features/US of value in our Backlog
-Might also display all our risks on our Prob/Impact Matrix in our info radiator
-Prob: High(5), Impact: High(5): 5X5=25(red)

Question 18

Insert images slide 15

What is the Risk Process In Agile and it’s steps?

Answer 18

Risk is always an iterative process(not linear).

Iterative Risk Steps(Repeated every iteration):
1. Plan Risk Management
2. ID Risks
3. Perform Qualitative Risk Analysis
4. Perform Quantiative Risk Analysis
5. Plan Risk Responses
6. Implement Risk Responses
7. Monitor Risks.
8. Repeat back from Step 2.

Question 19

How are agile ceremonies used to manage risk?

Answer 19

Agile planning: Make sure risk mgmt activities are occurring on project.
* Iteration planning can be used to educate PO on selecting USs based on Biz Value and Risk Reduction.
* Daily Standup: Impediments, blockers, for early sights of threats.
* Demonstrations:
* Retrospectives: Can be used to ask if we’re managing our risks effectively and are there any new escalating risks we need to take action.

Risk Adjusted BL: Name give to BL that have Risk Response Activities incorporated into them.
* They’re created by working w/ the PO to add threat avoidance, Mitigation activities and Opportunity enablement work into the BL.
* It’s a collaborative discussion between SM or team reps and PO.
-Team can explain the risk, impact, should it occur and..
-The PO Estimates and Compares the Expected monetary Value($$) of a risk w/ the value of the stories in the BL
-PO compares: Risk$$ vs Story Value$$(stories in BL)

Question 20

Insert image slide 15 Risk adjusted backlog

Wha are the Risk Adjusted Backlog steps?

Answer 20

1. ID all potential risks to project
2. Assess likelihood and impact of each risk(Qualitative)
3. Prioritize BL based on biz value and risk
   * Know steps before this how we got to risk adjusted backlog
   * Previous steps are ID risk, assess risk impact, Have Risk responses to show all data to PO. He decides.

4.Work highest priority items in backlog
5.Update risk adjusted BL regularly

PO decides whether to prioritize risk responses into BL or not.
When PO learns of potential risk impacts, can decide if and where RISK RESPONSE action should be placed.

Question 21

What are the 4 tenants of the Agile Manifesto?

Answer 21

1. Individuals and Interactions OVER Processes and Tools
   * Prefer to talk to people in person over sending emails
   * Emails still necessary but prefer in person.

2.Working Software OVER Comprehensive Documentation
* Prefer to have sw that actually works over documenting a ton on a big project.

4. 3. Customer Collaboration OVER Contract Negotiations
      * Prefer to work w/ customer or PO(reps cust) daily, check is feature right?
      * Instead of arguing over contract you didn’t do this as you said you would.
5. Responding to Change OVER Following PLAN
   * Agile supports responding to change by doing small releases, getting it in customers hands early, so if change to requirements we catch it early and make changes

While there is value in the RIGHT items, we value the items on the LEFT more.

Question 22

What are the 12 Agile Clarifying Principles?

Answer 22

1. Highest priority satisfy customer through early and continuous delivery of Valuable SW.
2. Welcoming changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.
3. Delivering working sw frequently, from couple of weeks to couple of months, w/ a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. Face to Face most efficient way to communicate information.
7. Working SW primary measure of progress.
8. Maintain sustainable pace indefinitley
9. Continuous attention to technical excellence and good designs enhances quality
10. Simplicity- are of maximizing the amount of work not done, is essential
11. Best architectures, requirements, and designs emerge from self organizing teams.
12. Regular intervals team reflects on how to be more effective, and ajusts behavior accordingly.

Question 24

What are the metrics of Kanbans Cumulative Flow Diagram?

Answer 24

Shows progress and bottleneck problems for Kanban continous flow.

1. Throughput: How much work your team delivers in a designated time period. Focuses on quantity of work completed, not time like the other metrics(cycle, lead time).
   - Cycle time/Lead time of each feature multiplied by number of features we’re delivering
   - How much we’re delivering and how often.
   - Cycle Time X #Features
   - Measured in EX: Tasks/day, User Stories/Week

2.Cycle Time(timebased): Time work on item being worked on.

3.Lead Time(timebased): Time takes from customer request to completion an delivery. Includes wait time.

4.Defect Cycle Time: Amount of time it takes for a defect/bug to be ID’d, resolved, and verified as fixed.
- Measures the efficiency and effectiveness of a teams defect resolution process.

Question 25

WhatKanban Ceremonies are there, that are different or similiar from SCRUM Ceremonies?

Answer 25

1. Daily Standups: similar to scrum. Discuss progress and blockers 2. Replenishment Meeting: Planning meeting on what should be added to kanban board - .. Othe meetings similar to Scum 3. Risk Review: Monthly review of potential risks impact teams work. | Kanbans Main purpose: To visualize workflow Secondary can be engagement

Question 26

What is the difference between Agile/adaptive, Iterative, and Incremental Approaches?

Answer 26

Agile: welcomes rapid changes to requirements, and can change direction after every iteration if new reqs or prtz come up. No future planning - Adaptive/Agile: Collecting reqs again seeing if they changed Incremental: Mini predictive projects(every proj is a feature), usually follow release plan for each individual feature. More strict on changing scope for each iteration. -Incremental: Acts as mini waterfall/predictive projects(increments) to deliver 1 feature at time. Analyze Requirements for this specific feature that was planned on feature release plan Differences: Agile: -Timeboxed iterations: short fixed durations sprints(2-4wks) -Regular Iteration Planning: At beginning of each sprint, team holds sprint planning meeting pick from PBL to go into SBL(w/in sprint duration) -Just in Time Planning: Planning focused on upcoming iteration only. -Team selects hughes priority items from backlog to do in sprint -Dynamic Prtzn: PBL continuously refined, new items added, based on changing priorities or emerging requirements. -Flexible and adaptable: Embrace change and adjust their plans based on feedback received during each iteration. Planning is iterative w/ continuous improvement and adjustment of process Incremental Phase-Based Iterations: Incremental projects might also use iterations, but usually aligned w/ project phase: ex design, development, testing Predictive Planning: Planning is done for each phase or iteration in advance, with detailed plans created for all planned work. Fixed Scope: Each iteration has predetermined set of tasks or features to be completed, and the scope does not change during iteration. Longer iteration durations: Longer than agile sprints, planning may cover larger scope of work. Less Flexible: Changes to plan are less common during the iteration, and any modifications may require formal CC process

Question 27

When doe Backlog Grooming/Refinement Take place in Scrum Ceremonies? And what is invovled in Refinement

Answer 27

* When: Middle of a sprint. Purpose: Refine enough stories so team undertands what the stories are and how large the stories are in relation to each other. Involved: PO works w/ team to prepare stories(make small enough) for upcoming iteration/sprint during 1 or more sessions in the middle of the iteration. * Team discuss items, ask questions for clarity, and provide effort estimates based on complexity and amount of work required to complete them. * LB Grmg invovles Re-prioritization of BL items. Top priority top of list, which can change. * Helps team better understand Product Roadmap and work ahead. | Refinement meetings allows PO to present story ideas to team and for tea ## Footnote Refine US small enough to be able to complete 1 per day.

Question 28

What's the difference between BL Grooming and Sprint Planning?

Answer 28

BL Refinement/Grooming: Continuous process that ensures the PBL remains relevant, updated, and prioritized for smoother sprint planning sessions. * Po presents BL items to team, explaining each items objectives and value to end product. * Team discusses items, asks questions for clarity, and provides efort estimations based on complexity and amount of work required to complete them. * Re-prioritizing BL items. Team may move items up or down depending on changes to scope, customer needs, or the PO strategic vision. Ensuring most critical items moved up top of list to work on next sprint. * All in an effort to keep PBL updated, clean, and ready for sprint planning. * Helps team bettter understanding Product Roadmap. Sprint Planning: Process of deciding what to work on in next sprint. * Backlog already groomed. * Look at our velocity and capacity and choose what goes in next sprint.

Question 29

Difference between Release Planning and Product Roadmap?

Answer 29

Product Roadmap: High level strategic, focused on long term goals/milestones. * Goal: Communicate overall vision and strategy for product. * Participants: Invovles broader SHs, including executive management. * In years Release Planning: Deatiled release plan specifying the features, timelines, and milestones for upcoming release(feature). Use PRM to make release plan. * Goal: Ensure detailed lpanning and execution for the next product release. * Participant: Scrum team mainly and immediate Shs. * Detail level: More detailed than Product roadmap. Focusing on specific * Estimate number of sprints needed to complete feature release for Q1 * Choose features contained in each iteration. Prod Roadmap could outline major features and goals | Example Scenarios: ## Footnote Summary * Product Roadmap: Informs release planning, by providing the strategic context and long term goals. * Release Planning: ensures that the steps taken in each release are aligned w/ roadmap. And contribute to the overall vision.

Question 30

What are the different types of Project Estimating techniques in Agile

Answer 30

1. Affinity Grouping/Estimating: Groups similar sized items together, allowing for rapid estimation of large backlog. Points or other estimation assigned to the groups/buckets for further planning. 2. Analogous Estimating: Comparing to something similar like past project. 3. Three Point Estimating: (O+4ML+P)/6 or (O + ML + P)/3 4. Parametric Estimating: Based on a parameter $50/hr 5. Relative Estimating(Agile): Estimated by how their size or complexity relates to other estimates(starting w/ the small User Story). - T-Shirt Sizing -Story Point Estimating: Fib numbs: 1 2 3 5 8 13 21 -Smallest item 1sp, US twice as big=2. 6.Planning Poker: Use cards that represent Fib Numbers to estimate size of features. - Team members discuss and privately select cards representing their estimates, revealing them simultaneously to reach a consensus. - This method avoids detailed time-based estimates, focusing on relative size and speeding up the estimation process. 7.Dot Voting: Each team member given 5 dots. Each place their dots on highest priority item the’yre voting on. Dots can be all on 1 item or multiple options. 8.Wideband Delphi: Multiple rounds of estimating as a group: starts broad, becomes more accurate as the highs and lows discuss and adjust. Predictive: Bottom Up Estimating(traditiona | Agile : Top down Estimating ## Footnote Delphi(not wide band): Multiple round of experts anonymously estimating.

Question 31

The Team thinks they can deliver feature in 6 weeks, but feature is large and complex. The Lead dev said worked on similar feature in another company, took them 4 months. Which Estimation will we take? A. Analagous Estimating B. Team Relative Estimating

Answer 31

Analagous guess from a lead dev(expert judge) and longer timeframe than teams relative estimation safer. And tied into actual experience on feature.

Question 32

What is a slack card? And how does it help w/ Quality?

Answer 32

Agile Used to refactor(clean up) code regularly. Help Prevent Technical Debt(future issues from messy code) * A slack card of 3-5pts can be added to sprint for tech debt. * Can drop off slack card if urgent card arises. | Agiles way of built in quality

Question 33

What is Technical Debt

Answer 33

Cost of having to go back and resolve problems that arise because of an earlier decision to take the easy route/shortcut instead of the best one when executing a project. * Incurring debt for project that has to be paid back later. Just like money debt, technical debt will accrue interest. * Making it harder to implement those necessary changes later. * Maintained by Refactoring code regularly- Slack card during sprint.

Question 34

What is the "Parking Lot"

Answer 34

Agile Term A Technique used in Daily Standups, to keep team meeting on track. If a group conversation is in danger of veering off topic, can put that particular topic in the hypothetical parking lot. * So parking it for later so your team can focus on more pressing issues. * Issue that’s brought up during standup can derail 15m meeting, parking lot it so We don’t solve it during stand up. * Get someone to help with issue but after meeting separate meeting.

Question 35

What are the 3 C's of User Story Creation?

Answer 35

1. Card: Customer and team agree on a user story, and written as index card. W/ just enough info to ID the project requirements. * ESSENCE of requirements 2.Conversation: A conversation between(3 people/Triad): Customer/PO, devs, testers(TRIAD). To work through the requirements, solution, and acceptance criteria [SPECIFICS] * SPECIFICS of US(elaborated) * Expansion of the description, are then added to the card. -Custome/PO give requirements -Devs: Give solution ideas -Testers: Give ideas on test acceptance criteria * Acceptance Criteria: Devs require clear acc.crit written on card. These are the conditions product must satisfy to be accepted by customer. -Means that there are testable items, which can help the test team to build acceptance tests for engineers to develop. -Condition 1, Condition 2, to be met/testable for completion of card. 3.Confirmation: Confirmation that the item meets the requirements. * Customer/PO can sign off the requirements(US). Make sure that’s what they want. * Once it’s completed and developed: Can Showcase increment at sprint review * Ensure a DoD is in place

Question 36

What is the DoD and DoR? And when are they created?

Answer 36

* DoR & DoD Creation: In Initial meeting(Sprint 0) before project starts. * DoR: Teams Criteria for when a US is ready to be analyzed or developed. -DoR: Checklist/guideline used during Backlog Refinement, to make sure US’s ready for next sprint. -Most teams start w/ blank DoR, and add to it over time. Example DoR checklist: 1. The acc.crit is clear 2. the test is written(for TDD) 3. A mock up is provided 4. the customer has reviewed. DoD: The team’s criteria for when a User Story is complete. Example DoD Checklist: * Code is Complete * Tests have passed * PO has Approved DoD & DoR: Discussed and edited during Sprint Retrospective, based on new exp or knowledge.

Question 37

What is a Business Admins Role in Scrum vs Pred project?

Answer 37

* Pred: BA usually gathers reqs, solutions, match to scope, makes WBS for whole deliverable. * Agile: Does this iteratively each sprint. In timeboxes works on highest priority items first, updates the estimates then reprioritizes

Question 38

What does a BA do in Scrum?

Answer 38

Before Sprint Planning * Requirement Clarification: Before Sprint planning meeting, BA works w/ PO and SHs to gather detailed requirements for high priority items. During Sprint Planning * Engage BA's in Sprint Sprint Planning: During sprint planning meetings, involve BA to help define the highest priority items Define and Refine Requirements Iteratively: * Instead of gathering all requirements upfront, BA will work on refining requirements incrementally. Timebox Requirement Gathering: Set specific timeboxes for BAs to gather and refine requirements for each sprint(First 2 days of sprint). Collab on User Stories: BAs work closely w/ the PO and dev team to write and refine USs Continuous Feedback loop: After each sprint gather feedback on delivered increments. BAs use this feedback to refine requirements and USs for future sprints. Participate in Sprint Reviews and Retrospectives * BAs participate in sprint reviews to understand the delivered work and gather insights for future requirements. Updating and Reprioritizing the Backlog * Based on the updated estimates and the work completed in each sprint, BAs help reprioritize the backlog ## Footnote Requirement Clarification: Before Sprint planning meeting, BA works w/ PO and SHs to gather detailed requirements for high priority items. BA ensures reqs documented in the form of US, Acc.crit. 1. Engage BA's in Sprint Planning During sprint planning meetings, involve BA to help define the highest priority items. Isn't sprint planning just to pick items from PBL? What's happening during this sprint. Ensure that BAs provide input on the requirements and scope for the items. 2. Define and Refine Requirements Iteratively: Instead of gathering all requirements upfront, BA will work on refining requirements incrementally. Focus on the most important and immediate requirements needed for the high priority items in the backlog. 3. Timebox Requirement Gathering: Set specific timeboxes for BAs to gather and refine requirements for each sprint(First 2 days of sprint). This ensures that requirement gathering does not become an extended process and aligns with the Agile principle of delivering value quickly. 4. Collab on USs BAs work closely w/ the PO and dev team to write and refine USs. Ensure that user stories are clear, concise and contain sufficent detail to be actionable w/in the sprint. - Have CGPT give example of what a sprint looks like step by step and how the ba is involved in the process. 5. Continuous Feedback Loop After each sprint gather feedback on delivered increments. BAs use this feedback to refine requirements and USs for future sprints. This allows for CI and adaptation of the requirements based on actual user feedback and evolving project neds. 6. Participate in Sprint Reviews and Retrospectives BAs participate in sprint reviews to understand the delivered work and gather insights for future requirements. In Retrospectives, discuss what worked well and what needs improvement in the requirement gathering and refinement process. 7. Updating and Reprioritizing the Backlog Based on the updated estimates and the work completed in each sprint, BAs help reprioritize the backlog Ensure that new insights or change in biz priorities are reflected in the backlog keeping it dynamic and responsive to change.

Question 39

What is a Spike and when do we use, and what for?

Answer 39

A spike can be used during a sprint to timebox(few days) research or explore potential solutions or gather information related to a specific problem or requirement * Can be initiated to an item in the SBL or PBL * The primary purpose is to address **uncertainties** or **technical complexities challenges **that may arise during dev process. * Spike can help team understand scope and feasibility of a backlog item SBL or PBL, to make more informed decisions on how to proceed. * Spike is timeboxed activities aimed at acquireing knowledge , validating assumptions, or prototyping solutions to inform subsequent work. When not to use: * For Incomplete user stories after iteration. This is about US that are to big and need to be decomposed in backlog refinement not done w/ a spike ## Footnote * Scenario: PBL item that is prioritized for next sprint, is complicated and team has been stuck past few weeks. Not enough work for upcoming sprint. * Add work w/ Spike US, to research more complex issues.

Question 40

What are the 2 versions of Agile Life Cycle(not iterative or incremental)

Answer 40

Iteration Based Agile * Same size timeboxes(sp1=2w, sp2=2w, sp3=2) * Every sprint(timebox)/iteration done until perfect, to create desired feature. Flow Based Agile * (Kanban flow based pull system) * Team keeps pulling from PBL, to max out WIP capacity(based on their capacity. * Sprint lengths can change, not same each one * keep going until final feature completed.

Question 41

Key wording for choosing between incremental and iterative: You are leading a project to design and manufacture a new consumer product. The project requires extensive prototyping and testing to ensure product quality and customer satisfaction. The project team consists of engineers, designers, and product testers. Which project management methodology should you choose from the list? a. Incremental b. Predictive c. Hybrid d. Iteratie

Answer 41

Ans: Incremental Wording: Extensive prototyping and testing. * The key here: This project invovles multiple(Incremental) functional increments **rather than a single evolving prototype(Iterative lifecycle)** * Incremental Life cycle: - This allows iterative development where team can test, review, and refine the product after each increment. - Given that project needs extensive protoyping and testing, incremental approach allows for continuous feedback and improvement, which helps ensure product quality and customer satisfaction. * Each version building on the last, refining the app with each version. * It allows iterative development and refinement of product based on testing and feedback ensuring high quality product. ## Footnote Incremental: All project steps done in each increment, each iteration is like 1 project. So Testing is apart of those steps. It1: Analyze>Design>Build>Test>Deliver= Feature 1 It2:... = Feature 2

Question 42

What is a time-box and it's use? Hows it different from an iteratin/sprint?

Answer 42

Time-box is where a fixed amount of time(timebox) is allocated to complete a task or set of activity, such a in iteration or sprint. * Sets a strict timeframe within which a team works to achieve specific objectives, regardless of completion * Duration: Can be any length, but commonly ranges from few hours to several weeks. * Focus: Emphasis is on working within a set period to encourage productivity, and efficiency. When time expries, the task is stopped, reviewed, and adjusted based on what was accomplished during the timebox. Differences * Iteration broader concept encompasses cycles of work to refine a product. * About refining through repeated cycles. * Sprint: specific type of timeboxed iteration used in SCRUM(agile) to deliver shippable increments. * Agile focused timebox iteration aimed at delivering product increment. * Timebox: General concepts sets timelimit on any activity, promoting discipline and time management. * Fixed time limits to any tasks, drivingfocus and efficiency.

Question 43

What is a Test Run?

Answer 43

Process of executing tests within agile development to validate functionality, quality, and performance of the software or productbeing developed. This testing approach is tightly integrated into agile workflow and supports continuous feedback and iterative improvement. * Testing phase in agile dev: Continuous integration testing, automated testing, TDD, BDD, exploratory testing.

Question 44

What is Incubation?

Answer 44

Incubation separate phase/process where ideas and concepts are developed in controlled environment before integrated into project.

Question 45

What is Feature Driven Development? FDD It's steps?

Answer 45

An Agile methodology focusing on delivering working software by developing features—small pieces of usable functionality that bring business value. It's particularly suited for** large, complex projects **with **clear requirements.** * Features: Small functional units that provide value to the user. * The focus is on planning, designgin and building these features sequentially. FDD Iterative Process: FDD** consists of five main activities** performed iteratively 1. Develop High-Level Model: Create an overview of the system. 2. Develop Features List: Define all features from the model. 3. Plan by Feature: Prioritize features and plan their development. 4. Design by Feature: Focus on designing individual features. 5. Build by Feature: Code and test the feature, then integrate it. ## Footnote FDD is scalable and suitable for both small and large teams(Feature teams).

Question 46

What are Feature Driven Developments Engineering Best Practices?

Answer 46

* Feature Teams: Teams dedicated to specific features. * Individual Class Ownership: Each class (group of code) is owned by a single person. * Domain Object Modeling: Use models like sequence or context diagrams to represent the system. * Inspections: Regular code and design inspections(Pair programming. * Configuration Management: Manage versions of changes systematically. * Regular Builds: Continuously integrate code into a test system. * Visibility of Progress: Track progress through visible metrics like Kanban boards.

Question 46

What are Feature Driven Developments Roles?

Answer 46

* Project Manager: Oversees the entire project(progress, budget, scope). * Chief Architect: Oversees, plans and manages the overall design of system architecture. * Development Manager: Leads the feature design and implementation, mentors/leads development team daily. * **Chief Programmer**: Designs and analyzes features, often managing small teams. * Class Owners: Responsible for designing, coding, testing, and documenting features. Works closely w/ chief programmer to implement features.. * Domain Expert: Provides business knowledge and makes sure requirements are met, w/ insights into customer needs. Role interdependencies * Chief Architects design desigion influence the chief programmers work, while chief programmer provides feedback on design feasibility and implementation. * Chief Programmer: oversees dev process and guides Class owners. * Class owners rely on Domain experts for accurate requirements and domain knowledge to ensure feature relevance and correctness. * Domain experts input helps the chief architect make informed decisions based on biz needs. | Heavy reliance on Chief Programmer

Question 47

What are advantages and disadvantages of FDD?

Answer 47

Advantages: * Scalable and suitable for both small and large teams. * Well suited where mult teams work together on common portfolio of projects because of structured feature focused approach. * FDD simplifies coordination between teams for large scale project invovling multiple teams, breaking down work into manageable defined features. * Focus on delivering complete, usable features. * Organizes development around specific features, making it easy to plan, track, and release functionality across teams. Approach provides clear visibility of what each team is working on, aligning efforts towards common portfolio goals. * Reduces errors and improves tracking by breaking work into smaller, manageable chunks. Disadvantages: * Heavy reliance on the** Chief Programmer**, to guide the design and ensure each feature aligns w/ overall architecture, making it ideal for complex highly technical environments. * May struggle with systems that need more flexible, collaborative approaches, because relies on documentation to communicate. * Emphasizes code ownership, which can hinder integration with other systems.

Question 48

What's the difference between FDD and Scrum?

Answer 48

* FDD: Structured, sequential, **feature-driven**; suited for large-scale, **complex projects with clear requirements.** * Sequence driven: Follows structured approach, starting w/ overall model, and progressing throuhg feature-specific design and build design phases. * Suited for Clear requirements and complex project. * Scrum: Flexible, iterative, sprint-based; suited for projects needing rapid changes and frequent feedback. Focuses on user stories rather than features * User centric customer driven(Customer POV), each sprint allows for adjustments based on feedback ensuring product evolves. * Suited for: Rapid changing requirements

Question 49

How would an FDD project for a banking application look like compared to a Scrum project?

Answer 49

* Project: Building a banking application. * Process: Model the entire system, list features (e.g., cash deposit, withdrawal), and develop each feature sequentially. * Outcome: Each release adds a fully functional feature that the customer can use, delivering value incrementally. Comparison to Scrum Example: * FDD Project: Highly structured with clear upfront modeling and sequential feature development. * Scrum Project: Iterative and flexible, focusing on continuous user feedback and evolving requirements. FDD is ideal when the project requires a detailed design upfront and benefits from sequential development of well-defined features, while Scrum is best for projects that need adaptability and rapid feedback cycles.

Question 50

What's the difference in release planning for Scrum vs FDD?

Answer 50

* Approach to Planning: * **Scrum**’s release planning is **iterative** and **evolves over time**, * **FDD**’s release planning is **sequential** and **feature-centric**, with more emphasis on **detailed upfront planning.** * Flexibility: * Scrum’s release **planning** is **highly flexible** and **adaptive to changes** * FDD’s approach is more **rigid** and **structured**, suitable for **projects with clear requirements.** * Focus: * Scrum focuses on **delivering increments** through **Sprints** based on user **feedback**, * FDD emphasizes **delivering complete**, **usable features **as the **primary units of work.** * Responsiveness to Feedback: * Scrum allows for c**onstant feedback** and **adjustments in release planning, ** * FDD **collects feedback after feature delivery** and **integrates** it into **subsequent iteration**s in a **structured way.** Overall, Scrum’s release planning is designed for adaptability and quick adjustments, while FDD’s is designed for structured, predictable feature delivery, making each methodology suited to different types of projects and organizational needs. ## Footnote FDD more structured, wait until feature done, then get feedback. Scrum: wait until sprint done, feedback then can change.

Question 51

Which role could substitute the PO if he's to busy to come to meetings for different project teams? a. Technical lead of the project who knows the detailing of the product b. A customer care executive who interacts with real users on a daily basis c. The UX designer since they have close proximity to the business and knows how the UI is expected to behave d. A project coordinator who reports to you and understands the business linkage with product features

Answer 51

**ans: Project Coordinator**- This person has a direct understanding of the **product features**, the vision, and the business objectives, which enables them to make informed decisions when needed. * Undersands PO's role best in terms of understanding the product’s business objectives, managing stakeholder expectations, and making prioritization decisions. * best representative to ensure continuity in decision-making during the Product Owner's absence. * Responsiblities: Manages **project schedules, coordinates between teams, and ensures alignment with business goals.** * Acts as a liaison between the Product Owner and the development team. Strengths: Understanding of **business context** and **project linkage**, good at managing day-to-day activities and decisions. Ideal for: Representing the Product Owner in their absence due to their u**nderstanding of both business and project aspects.** * Product Owner (PO): Defines product vision, prioritizes backlog, and makes key decisions to deliver value. * Technical Lead: has in depth technical technological knowledge of the products technical aspects. * Missing business context and customer perspective needed to make strategic decisions. * Customer Care Executive: Provides insights into user needs and feedback. * Handles customer inquireies, complaints, and feedback. * Not equipped to to make product dev decisions or prtz features. * Focus on end user experience, rather than broader product strategy. * UX Designer: Focuses on user experience/interactions w/ product and interface design. * Lacks holistic view of biz goals, prioritization, and strategic decision making. * Expertize is specialized doesn't cover ful scope of Product owners responsbilities. * Project Coordinator: Manages project schedules and coordinates between teams, understanding both business and project aspects. Ideal for representing the PO in their absenc

Question 52

Come back make cards Agile Project Management phases. Ray text book p 1045

Question 53

What are the steps for in Agile project Closing Phase?

Answer 53

1. Finalize Deliverables: o Ensure that all user stories or backlog items have been completed. o **Conduct a final sprint review** where the team **demonstrates the completed work to stakeholders.** 2. Obtain Client/Stakeholder Approval: o In Agile, this often happens continuously at the end of each sprint. At project closure, you **confirm that all deliverables meet the Definition of Done** and are a**ccepted by the client or stakeholders**. 3. Conduct a Retrospective: o This is where the **FINAL lessons learned are discussed. ** The team **reflects** on the **entire project** to identify what went well, what didn’t, and areas for improvement. This information is crucial for future projects. o Lessons learned are a vital component of project closure as they help the organization refine processes and avoid repeating mistakes in future iterations. 4. Update the Organizational Knowledge Base: o After the retrospective, the **lessons learned are formally documented and shared with the wider organization**. This step ensures that other teams can benefit from the insights gained in the project. o In Agile, this is a **key closeout step**, as continuous improvement is fundamental to the agile philosophy. 5. Release or Transition the Team: o Once the **project is officially closed**, the **team** is either **disbanded** or reassigned to other projects. 6. Archive Project Artifacts: o Any relevant project documents, user stories, test cases, and release notes are archived for future reference. 7. Celebrate and Recognize Success: o Celebrate the team’s accomplishments and recognize contributions. This builds team morale and provides closure to the project.

Question 54

What is the cause of a Swinging back and forth project completion date in agile?

Answer 54

Poor story estimation. Resolve w/ making sure PBl are elaborated in more detail, so we don't guestimate. If we guess on story point estimation will cause more variablity in project finish date..

Question 55

# Rey Mock Set 2: Q60 Agile Project Tailoring: Transitioning from Pred to Agile. Execs have no buy in for agile. What does it mean by " Finding common ground and areas of improvement based on the project needs and then use **experiments** to progress?

Answer 55

1. Finding Common Ground: PM and execs should ID shared goals both care about, like improving project delivery speed, enhancing product quality, satisfy customer needs. Helps build alignment between execs and agile team. * Execs may not fully understand agile or see its value, but they care about business outcome. By finding areas agile can help achievethese goals, easier to gain their support. 2. Using Experiments: Refer to trying out new practices, techs, or processes on small scale to test their effectiveness. It's a way to validate ideas before fully commiting to them, which aligh w/ agile proactive of iterative improvement. * Benefit: Low risk and low cost, but provide valuable insights. Allow team and execs to learn first hand how agile can address their pain points. * Experiments allow you to introduce agile gradually instead of all at once, and gather data to show how it works/benefits. * Examples: * 1. Sprint Duration: Team can experiment w/ sprint length(2wks vs 3wks) to see which duration delivers better results. * 2. Agile Ceremonies: If org new to agile, might introduce one agile ceremony, like daily standups, to demo how it improves comms and transparency. * 3. Prototyping or Small Releases: Team could experiment w/ releasing smaller incremental updates to a product to showcase how agile delivers value quickly and iteratively, helping execs see it's benefits.

Question 56

# [](http://) What is the tailoring suggestion for the situation: Very Large Teams. | Dbl Check APG make sure accurate p. 121

Answer 56

* Break down large projects into smaller projects. * Conduct technology trials before implementation. * Use smaller, more frequent releases and reduce team size to core members. * Break large teams into smaller ones and use program management for coordination. * Consider using scaled frameworks like DA, SAFe®, or LeSS, though these carry risks.

Question 57

What is the tailoring suggestion for the situation: Dispersed Teams | Dbl Check APG make sure accurate p. 121

Answer 57

* Use tools like instant messaging and video conferencing for better communication. * Hold face-to-face meetings early to build trust for future remote work. * Use round-robin check-ins in remote meetings and iteration-based approaches for better coordination across time zones.

Question 58

What is the tailoring suggestion for the situation: Some **safety critical products** may require additional documentation and conformance checks beyond what agile processes suggest out-of-the-box. | Dbl Check APG make sure accurate p. 121

Answer 58

* Add documentation and conformance checks to agile processes. * Consider using a hybrid approach combining agile with necessary additional controls for documentation and reviews.

Question 59

What is the tailoring suggestion for the situation: Stable Requirements. | Dbl Check APG make sure accurate p. 121

Answer 59

* Question if agile is necessary when requirements are stable and change is minimal. * If feedback cycles don’t refine requirements, extend cycle durations to reduce costs. * Use a hybrid approach when design phases are dynamic but rollout is predictable.

Question 60

What is the tailoring suggestion for the situation: Functional Silos. | Dbl Check APG make sure accurate p. 121

Answer 60

* Encourage self-organized cross-functional teams without management intervention. * Align the compensation system to reward teamwork over functional performance.

Question 61

What is the tailoring suggestion for the situation: Transparency Fear. | Dbl Check APG make sure accurate p. 121

Answer 61

Lead by example, demonstrating transparency using status boards or whiteboards to ease fear around openly sharing progress and issues.

Question 62

What is the tailoring suggestion for the situation: Inexperienced Teams. | Dbl Check APG make sure accurate p. 121

Answer 62

For inexperienced teams, provide help with assigning tasks rather than leaving everything to self-direction. Consider building centers of competencies to guide and teach.

Question 63

What is the tailoring suggestion for the situation:Lack of Executive Buy-In. | Dbl Check APG make sure accurate p. 121

Answer 63

* Find common ground and use experiments to gain progress. * Provide agile education for executives and relate agile concepts to lean thinking like short cycles and frequent reviews.

Question 64

What is the tailoring suggestion for the situation: | Dbl Check APG make sure accurate p. 121

Answer 64

* Adjust terminology to fit the organization’s culture. For example, avoid terms like "game" if it’s seen as unprofessional, and use "workshop" instead. * Adjust terminology to fit the organization’s culture. For example, avoid terms like "game" if it’s seen as unprofessional, and use "workshop" instead.

Question 65

Who accepts or rejects completed user stories during a demo/sprint review where agile team illustrates the features and solicit feedback? Why and why not for each role? a. PO b. Project Sponsor c. Customer

Answer 65

a. PO: After reviewing the demo, the Product Owner checks if the user stories meet the acceptance criteria and product vision, making them responsible for accepting or declining them. b. Sponsor: typically a senior stakeholder providing support and resources but does not have a direct role in the day-to-day review of user stories. This responsibility lies with the Product Owner, who represents the customer’s needs. c. While the Product Owner represents the customer’s interests, the actual customer does not typically participate in story acceptance in Agile teams. The Product Owner ensures the customer’s requirements are met by accepting or rejecting stories

Question 66

What's the difference between a burn up and burn down chart?

Answer 66

Burn Up Chart: Total completed work vs Planned work * Shows the amount of work completed over time compared to the total amount of work. * It tracks progress made toward the completion of the project or sprint. * Usually at the release level, but still good at sprint level. * 3 lines: Planned, Actual, Scope(Top horizontal line that caps endpoint of story points for project to be completed. * The chart starts at zero and increases as tasks or story points are completed, while a second line shows the total scope of work. * Scope Changes Burn Up: * Does not explicitly track scope changes (e.g., if more tasks are added or removed). * If scope changes occur, the burn-down chart may seem inconsistent because the total amount of work might change without an obvious explanation in the chart. Burn-Up Chart: Track remaining work to be completed down to 0 story points * Usually at sprint level * Scope Changes: Easier to track in Burn up chart * Clearly shows scope changes. * If more work is added to the project, the total scope line (the upper line) moves up, making it easier to track the impact of these changes on project progress.

Question 67

What are the steps for 2 iterations in iterative life cycle?

Answer 67

1. Concept 2. Iteration1: a. Plan1 b. Design c. Build Feedback 3. Iteration2: a. Plan2 b. Design2 c. Build Successful Prototype

Question 68

How can you integrate security in agile w/ for example a compliance security officer? Who is not happy not being invovled in past 3 iterations? A. Ensure that a data privacy team member attends every future daily standup? B. Request the data privacy officer assign a data privacy team member to join the project team. C. Set up a meeting with the data privacy officer to identify and implement a process(structured plan) to meet requirements.

Answer 68

Ans: C. Set up a meeting with the data privacy officer to identify and implement a process(structured plan) to meet requirements Agile Security stresses that i**ntegrating** security (or privacy) into Agile projects r**equires deliberate inclusion through processes** that ensure security requirements are met during development. The article recommends collaborative discussions to align security measures with Agile delivery. Solution offers structured approach to incorporating secury into our agile project by collaborating w/ SH.

Question 70

# Word Trick Estimated vs Complete SP? A project management organization needs to assess the performance of two project teams. Both projects have the same scope of work, but Team 1 works virtually and has calculated 100 story points, while Team 2 works in the office and has calculated 80 story points. Which team has the better performance? A.Team 1 because they work virtually. B.Team 2 because they work in the office. C.Team 1 with 100 story points performed better than Team 2 with 80 story points. D.Team 2 with 80 story points performed better than Team 1 with 100 story points.

Answer 70

**** Solution: C. Team 1 with 100 story points performed better than Team 2 with 80 story points. Why I got wrong: * Question wordy tricky: Didn’t clearly say story points were estimates or completed story points. * **Question Clues** on it being completed story points. * **Comparison in Performance**: The question asks which team has "better performance," which suggests that it is evaluating what the teams have accomplished, not just what they have planned. * If the story points were merely estimates, it wouldn’t give a clear picture of performance. * Wording in answer C: Answer C states, "Team 1 with 100 story points performed better," implying that the 100 story points refer to completed work, not just an estimate. * This** use of "performed" links the number of story points to actual output.**

Question 71

How does problem solving occur in agile scrum? Whats the PM/SM and Agile teams role in this?

Answer 71

PM/SM: Facilitate the meeting Scrum Team: Use their collective wisdom in assessing and deciding how to proceed when issues come up.

Question 72

What is a Minimum Viable Product?

Answer 72

A concept used to **DEFINE THE SCOPE** of the **first release of a solution** to customers by identifying the fewest number of features or requirements that would deliver value.

Question 73

In Agile which are costs of change and not for quality? A. Shorten the defect cycle time. B. Fix escaped defects. C. Support more features. D. Reduce the technical debt.

Answer 73

A. Shorten the defect cycle time: Series of steps defect goes through from Identification to it's resolution. B. Fix escaped defects. C. Support more features: Not part of cost of quality. D. Reduce the technical debt: Rework later Solution: C. Support more features The scrum master is referring to all the listed options, e**xcept supporting more features.** In regards to the cost of change, the cost of quality (COQ) measures the** total costs required to prevent, identify, and deal **with the **results of defects in deliverables.** The cost of poor quality is higher the later the defect is found and will impact the length of the cycle time.

Question 74

During agile project if you have a team unfamiliar w/ formal requirements prioritization methods and are inexperienced with agile delivery approaches. The PM wants to ensure critical business requirements will be planned and delivered. What prioritization technique shoudl the PM use? A. Get the opinion of all team members and business stakeholders. B. Use a mathematical model defined by the team members and stakeholders. C. Collect the needs of the team members and business stakeholders. D. Reach a common understanding with the team members and stakeholders.

Answer 74

B. Mathematical model defined by team members and Shs For prioritization we want an o**bjective approach** like business value among other factors **not subjective**. Since team inexperienced in agile want structured objective approach to prioritize so lack of experience is accounted for. Structured and data driven approach like mathematical model removes subjective opinions and ensures a consisten objective prioritization process. All other options are subjective approaches.

Question 75

When can a sprint backlog be changed in the middle of a sprint or SBL item be removed?

Answer 75

APG: says PO is understanding if team member unavailable for some reason(PTO, leaves company), and that teams capacity will drop so can’t finish same amount of work(SPs) as previous sprints anymore. * So removing items from SBL is ok if PO approves. * **Sprint backlog can be unlocked if PO approves it.**

Question 76

If team working on an issue for few weeks and can't figure it out because of technical challenges(technical gap) and lack of knowledge what can a PM do to help? A.Escalate the case to a functional manager to bring a technical expert to the team. D.Update the issue and risk logs, including the action plan to resolve the issue.

Answer 76

Ans A An ideal pm can get external support to bridge technical gap. He is helping team remove impediment/blocker. Escalating to a functional manager for support ok. D wrong because if team was already working on issue for few weeks you can assume it was already logged, and it doesn't directly address the issue of technical gap.

Question 77

How does a PM ensure Benefits realization in agile? A.Evaluate the realization of benefits during team standup meetings. B.Align the benefits management plan with the product backlog. C.Evaluate the benefits management plan at the end of the sprints. D.Ask the scrum master to provide daily updates about the benefits realization.

Answer 77

**Aligning the benefits management plan with the product backlog **ensures that the project is **driven** by the **most valuable features** and **objectives** that **align with organizational goals. ** The benefits management plan should identify the specific benefits that the project aims to achieve and the product backlog should be prioritized based on those benefits. This will ensure that the team focuses on delivering the most valuable features first and that each sprint contributes to benefits realization.

Question 78

What is Working agreements and when is it made?

Answer 78

Working agreements: Serves as team charter in agile Can include the following: What team defines as "Ready" (DoR): So the team can take in work. What team defines as “DONE”(DoD): So team can judge completeness consistently of features/US. Can include What Team defines what done is. These are the projects release criteria. So team can judge completeness consistently Respecting timebox: Team can make rules for not messing w/ time boxed work Use of work in process limits: Team can set work capacity if using kanban WIP.

Question 79

In Agile the Teams social contracts(team charter) is how team interacts with each other. Don't need a formal team charter as long as they have social contracts in place. What are they?

Answer 79

Team Values: Sustainable pace and core hours of working. Working Agreements: DoR and DoD Ground Rules: Ex- Such as one person talking in a meeting at a time. Group Norms: How team treats meeting times.

Question 80

What are the two types of acceptance criteria in Agile?

Answer 80

User Story Acc.Crit: focus on what the story needs to do functionally. Specific conditions and functionality that must be met for that story to be considered complete. * Directly tied to the storys requirements and describe expectations from the users perspective DoD Acc.Crit: Is a checklist of acceptance criteria for all user stories or features, making sure every deliverable, regardless of functionality, meets a **minimum quality and readiness standard.** * Shared checklist or standard that applies to all user stories or features. providing a consistent, baseline standard that any deliverable must meet before it can be considered "done" by the team. * This his includes broader quality, integration, testing, and compliance standards that are necessary for a feature to be truly production-ready. * **Example** for validation and verification question acc.crit in the DoD. * acceptance criteria in the DoD often cover aspects like: * All unit tests and integration tests pass. * Code is reviewed and approved by at least one other team member. * Code is merged without conflicts and deployed in a staging environment. * The feature has been tested in staging and validated with any dependencies or other systems.

Question 81

What is a Testing Suite?

Answer 81

Collection of test cases designed to assess different aspects of an application’s functionality, performance, and reliability in an automated or structured way. It’s typically created to streamline the process of validating that the application behaves as expected under various conditions. Testing suites are essential tools for managing quality control, reducing defects, and enabling continuous integration. Types of Test Suites: Testing suites can be created for different levels of the application, including: * Unit Test Suite: Verifies individual functions or components in isolation. * Integration Test Suite: Assesses whether multiple components work together as expected. * System Test Suite: Checks the complete application in an environment that mimics production. * End-to-End (E2E) Test Suite: Tests the entire user flow from start to finish to ensure complete system functionality. * Acceptance Test Suite: Evaluates whether the application meets the end-user and business requirements. * Performance Test Suite: Assesses the application’s response times, resource usage, and scalability.

Question 82

# Clarify more What is functional point estimating?

Answer 82

Agile **quantitative estimation technique **for sw projects. to **estimate size, complexity, and effort.** * Measures functionality delivered to user from user POV, rather than focusing solely on technical aspects like code. Core Principles 1. User POV: Focus on what Sw delivers to end user(screens, reports, files) rather than internal tech details. 2. Standardized method:Uses predefined rules to evaluate size, complexity of sw 3. Independent of Technology: Works across programming langauages, dev envmts, or platforms.

Question 83

What are the 5 traints of a good user story?

Answer 83

INVEST: * Independent * Negotiable * Valueable * Estimateable * Small * Testable

Question 84

How does a PM/SM balance the responsibility of removing distractions/impediments from SH requests so team can focus on delivering value But Still collaborating/engaging w/ SHs.

Answer 84

* Establish clear roles and boundaries for SHs, such as engage w/ team and project: Can use Team working agreements SH Collaboration: SH contribute to project in a structured and mutually beneficial way. * Follow working agreements. Engagement is planned and coordinated w/ sprints reviews, planning sessions. * Sh work w/ team to refine requireemnts or clarify goals without dirsupting work flow. * Collaboration fosters trust, alignment and improved project process SH Interruption: SH disrupts workflow bypassing formal processes and working agreements with unstructured interactions * Engagement outside establisehd comm protocols * Distractions hinder productivity * SH request status update or changes directly to team, bypassing PM. Solution: * Working Agreements: Establish clear roles and boundaries for stakeholders, such as engaging through planned meetings or official communication channels. * Use tools like communication plans and t**eam working agreements **to define acceptable forms of interaction. * Address interruptions by educating stakeholders on the project processes and the importance of team focus. * Foster collaboration by inviting stakeholders to participate in appropriate project ceremonies, where their input is valuable and structured. * Immediate distraction solution: sponsor intervention