Agile Flashcards
What is the purpose for a User Story format?
What is the format of a US?
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
11 insert image
What is SAFe(Scaled Agile Frameworks)?
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.
What are the 3 Scaled Frameworks in Agile?
- 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.
What is Scrum of Scrums?
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.
10 Insert image
What is Large Scale Scrum(LeSS)?
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
Procurement
What does agile procurements aim for?
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
slide 9 insert image
What is the collecting requirements process in agile?
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.
Insert image slide 9
What are project Initiation steps in agile?
- 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.
What are the Agile Procurement Contract Types Multi Tiered Structure and Emphasized Value Delivered?
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.
What are the Agile Procurement Contract Types Fixed Price Increments and Not-To-Exceed T&M?
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.
What are the Agile Procurement Contract Types Graduated T&M and Early Cancellation?
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.
What are the Agile Procurement Contract Types Dynamic Scope Option and Bring the External Party into Team?
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
What are the 3 types of Impediments to agile team?
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.
What is an Impediment?
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.
What is an Obstacle?
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
What is a Blocker?
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.
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.
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)
Insert images slide 15
What is the Risk Process In Agile and it’s steps?
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.
How are agile ceremonies used to manage risk?
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)
Insert image slide 15 Risk adjusted backlog
Wha are the Risk Adjusted Backlog steps?
- ID all potential risks to project
- Assess likelihood and impact of each risk(Qualitative)
- 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.
What are the 4 tenants of the Agile Manifesto?
- 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.
- 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.
- Customer Collaboration OVER Contract Negotiations
- 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.
What are the 12 Agile Clarifying Principles?
- Highest priority satisfy customer through early and continuous delivery of Valuable SW.
- Welcoming changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.
- Delivering working sw frequently, from couple of weeks to couple of months, w/ a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- Face to Face most efficient way to communicate information.
- Working SW primary measure of progress.
- Maintain sustainable pace indefinitley
- Continuous attention to technical excellence and good designs enhances quality
- Simplicity- are of maximizing the amount of work not done, is essential
- Best architectures, requirements, and designs emerge from self organizing teams.
- Regular intervals team reflects on how to be more effective, and ajusts behavior accordingly.
What are the metrics of Kanbans Cumulative Flow Diagram?
Shows progress and bottleneck problems for Kanban continous flow.
- 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.
WhatKanban Ceremonies are there, that are different or similiar from SCRUM Ceremonies?
- Daily Standups: similar to scrum. Discuss progress and blockers
- Replenishment Meeting: Planning meeting on what should be added to kanban board
- .. Othe meetings similar to Scum - Risk Review: Monthly review of potential risks impact teams work.
Kanbans Main purpose: To visualize workflow
Secondary can be engagement
What is the difference between Agile/adaptive, Iterative, and Incremental Approaches?
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
When doe Backlog Grooming/Refinement Take place in Scrum Ceremonies? And what is invovled in Refinement
- 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
Refine US small enough to be able to complete 1 per day.
What’s the difference between BL Grooming and Sprint Planning?
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.
Difference between Release Planning and Product Roadmap?
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:
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.
What are the different types of Project Estimating techniques in Agile
- 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. - Analogous Estimating: Comparing to something similar like past project.
- Three Point Estimating: (O+4ML+P)/6 or (O + ML + P)/3
- Parametric Estimating: Based on a parameter $50/hr
- 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
Delphi(not wide band): Multiple round of experts anonymously estimating.
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
Analagous guess from a lead dev(expert judge) and longer timeframe than teams relative estimation safer. And tied into actual experience on feature.
What is a slack card? And how does it help w/ Quality?
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
What is Technical Debt
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.
What is the “Parking Lot”
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.
What are the 2 versions of Agile Life Cycle(not iterative or incremental)
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.
What is Feature Driven Development? FDD
It’s steps?
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.
FDD is scalable and suitable for both small and large teams(Feature teams).
What’s the difference between a burn up and burn down chart?
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.
