SAFe Scrum Master Study Guide 5.0

Agile frameworks

SAFeScrumCrystalKanbaneXtreme Programming (XP)Feature-driven development

What does a Scrum Master do?

- Servant leaders and coaches for an Agile Team. - Help educate team in Scrum, XP, Kanban and SAFe, ensuring the agreed Agile process is being followed.- Help remove impediments and foster an environment for high-performing team dynamics, continuous flow and relentless improvement.- Facilitates team events- Works with RTE to ensure train meets PI objectives- Fosters normalized estimating within the team- Assists the PO in backlog for PI and IP.- Attends scrum of scrum meetings.

Scrum Master Responsibilities

Exhibits lean-agile leadershipSupports the team rulesFacilitates the team's progress toward team goalsLeads team efforts in relentless improvementFacilitates meetingsSupports the POEliminates impedimentsPromotes SAFe quality practicesBuilds a high-performing teamProtects and communicatesResponsibilities on the trainCoordinates with other teamsFacilitates preparation and readiness for ART eventsSupports estimating

ART

Agile Release Train

PO

Product Owner

Program Increment (PI) Planning

A cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a common mission and vision.

Innovation and Planning Iteration

Occurs every PI and serves multiple purposes. It acts as an estimating buffer for meeting PI objectives, as well as providing dedicated time for innovation, continuing education, and PI planning and Inspect and Adapt (I&A) events.

Inspect & Adapt (I&A)

A significant event, held at the end of each PI, where the current state of the solution is demonstrated and evaluated by the train. Teams reflect and identify improvement backlog items via a structured, problem-solving workshop

Iteration

A basic building block of Agile development. Each is a standard, fixed-length timebox, where Agile Teams deliver incremental value in the form of working, tested software and systems.Cycle - Defines, builds, integrates, & test.

What is the recommended timebox duration for an Iteration?

2 weeks; however, 1-4 weeks is acceptable, depending on the business context.

Who participates in the Inspect & Adapt (I&A) phase?

All stakeholders, including:1. The Agile Teams2. Release Train Engineer (RTE)3. System and Solution Architect Engineering4. Product Management, Business Owners, and others on the Train

What results from the I&A phase?

Improvement backlog items that go to the Program Backlog for the next PI Planning event

3 parts of I&A

PI System DemoQuantitative MeasurementRetrospective and Problem-Solving Workshop

Purpose of PI System Demo

To show all the Features the ART has developed over the course of the PILeads: PM, PO, System TeamAttend: BO, Stakehlders, PM, RTE, SM & Teams

PI System Demo Timebox

~1 hr or less

What is one primary measurement to be considered in quantitative metrics?

Program predictability measureUpdated end of inspect & adapt event

Retrospective goal

To identify whatever issues they would like to address

Retrospective objective

To identify a few significant problems that the teams can potentially address - What went well, what didn't go well, what can do better next time.

PDCA Cycle

PlanDoCheckAdjust

Who facilitates the PI Planning event?

Release Train Engineer (RTE)

In which iteration does PI Planning take place?

Innovation and Planning Iteration

__ ________ is essential to SAFe; if you are not doing it, you are not doing SAFe.

PI Planning

Business Benefits of PI Planning

Establishing face-to-face communication across all team members and stakeholdersBuilding the social network the ART depends onAligning development to business goals with the business context, Vision, and team project PI objectivesIdentifying dependencies and fostering cross-team and cross-ART collaboratioProviding the opportunity for "just the right amount of architecture and Lean User Experience (UX) guidance)Matching demand to capacity, eliminating excess WIPFast decision-making

PI Planning Inputs

Business contextRoadmap and visionTop 10 features of the Program BacklogNFRs (Non-functional Requirements)

PI Planning Outputs

Committed PI objectives (A set of SMART objectives that are created by each team with the business value assigned by the Business Owners)Program board (this highlights the new feature delivery dates, feature dependencies among teams and with other ARTs, and relevant milestones)Plan is the goal

3 Areas of Preparation for a Successful PI Planning

Organizational ReadinessContent ReadinessFacility Readiness

Organizational Readiness

Strategic alignment and teams trains setup

Content Readiness

Management and development preparedness

Facility Readiness

The actual space and logistics for the event

Organizational Readiness Considerations

Planning scope and context - is the scope (product, system or technology domain) of the planning process understood? Do we know which teams need to plan together?Business alignment - is there reasonable agreement on priorities among Business OwnersAgile teams - Do we have Agile teams? Are there dedicated developer and test resources and an identified Scrum Master and Product Owner for the team?

Content Readiness Considerations

Executive briefing - a briefing that defines the current business contextProduct vision briefing(s) - briefing(s) prepared by Product Management including the top 10 features in the product backlogArchitecture vision briefing - a presentation made by the CTO, Enterprise Architect, or System Architect to communicate new enablers, features, and Nonfunctional Requirements (NFRs)

Facility Readiness Considerations

Facility - this room must be roomy enough for all attendees, with breakout rooms if necessaryFacilities/tech support - these people need to be identified in advance and reachable during setup and testing, and the event itselfCommunication channels - for distributed planing meetings, primary and secondary audio, video, and presentation channels must be available

Stretch Objectives

Goals built into the plan (e.g., stories that have been defined and included for those objectives), but are not committed to by the team because of too many unknowns or risks. These are NOT extra things to do in case there is time. Instead, they increase the reliability of the plan and give management an early warning of goals that the ART may not be able to deliverTime & capacity to do it, we plan for it, but are not committed to it

PI Planning Day 1 Agenda

Business contextProduct/solution visionArchitecture vision and development practicesPlanning context and lunchTeam breakouts #1Draft plan reviewManagement review and problem-solving

Business context

A senior executive/line-of-business owner describes the current state of the business and presents a perspective on how well existing solutions are addressing current customer needs

Product solution/vision

Product management presents the current program vision (typically represented by the next top 10 upcoming features) and highlights any changes from the previous PI Planning meeting as well as any forthcoming Milestones.

Architecture vision and development practices

System Architect/Engineering presents the architecture vision. Also, a senior development manager may introduce Agile-supportive changes to development practices such as test automation, DevOps, Continuous Integration, and Continuous Deployment, which are being advanced in the upcoming PI

Planning context & lunch

The RTE presents the planning process and expected outcomes of the meeting

Team Breakouts #1

Teams estimate their capacity (velocity) for each Iteration and identify the backlog items they will likely need to realize the features. Each team creates their team plan, visible to all, iteration by iteration

Draft plan review

Tightly timeboxed; teams present key planning outputs, including draft objectives, potential risks and dependencies. Business Owners, Product Management and other teams and stakeholders review and provide input

Management review and problem-solving

During this, management may negotiate scope changes and resolve other problems by agreeing to various planning adjustments. The RTE facilitates and keeps the primary stakeholders together for as long as necessary to make the decisions needed to reach achievable objectives

PI Planning Day 2 Agenda

Planning AdjustmentsTeam breakouts #2Final Plan Review and LunchProgram RisksConfidence votePlan reworkPlanning retrospective and moving forward

Planning Adjustments

The 2nd day of PI planning, the meeting begins with managers describing any changes to planning scope and resources

Team breakouts #2

Teams continue planning based on their agenda from the previous day, making the appropriate adjustments. They finalize their objectives for the PI, to which the Business Owners assign business value

Final Plan Review and Lunch

1. Changes to capacity and load. 2. Final PI Objectives with business value. 3. Program risks and impediments. 4. Q& A Sessions. - Collected in front of room. Reviewed by team. Business Owners asked to accept plan. If yes, plan/prog risk sheets next. If no, plans stay, teams cont. to work after review.

Program risks

During planning, teams have identified program-level risks and impediments that could impact their ability to meet their objectives. These are resolved in a broader management context in front of the whole train. One by one, the risks are addressed with honesty and transparency, and then categorized into one of the following categories: - Resolved: the teams agree that the issue is no longer a concern- Owned: someone on the train takes ownership of the item since it cannot be resolved at the meeting- Accepted: some risks are just facts or potential problems that must be understood and accepted - Mitigated: teams can identify a plan to reduce the impact of an item

Confidence vote

Once program risks have been addressed, teams vote on their confidence in meeting their program PI objectives. Each team conducts a fist of five vote. If the average is 3 fingers or above, then management should accept the commitment. If it's less than 3, the team reworks the plan. Any person voting 2 fingers or fewer should be given an opportunity to voice their concern. This might add to the list of risks, require some replanning or simply be informative.

Plan rework

This is done until a high confidence level can be reached. This is one occasion where alignment and commitment are valued more highly than adhering to a timebox.

Planning retrospective and moving forward

Finally, the RTE leads this for the PI Planning event to capture what went well, what didn't, and what can be done better next time.

3 pillars of scrum

1. Transparency2. Inspection3. Adaption

How are the 5 Whys used?

To identify a root cause(s) of a problem)

When does the Plan-Do-Check-Adjust cycle occur in Scrum?

At all formal Scrum events

Which type of enabler does a System Architect review during a System Demo?

Enabler portfolio epics

Enabler Stories

Support the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, infrastructure, compliance, and architecture development. They are captured in the various backlogs and occur at all levels of the Framework

Spikes

A type of exploration Enabler Story in SAFe. Defined initially in Extreme Programming (XP), they represent activities such as research, design, investigation, exploration, and prototyping. Their purpose is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.

Functional Spikes

They are used to analyze overall solution behavior and determine: How to break it downHow to organize the workWhere risk and complexity exist How to use insights to influence implementation decisions

Technical Spikes

They are used to research various approaches in the solution domain. For example:Determine a build vs buy decisionEvaluate the potential performance or load impact or a new user storyEvaluate specific technical implementation approaches Develop confidence about the desired solution path

What is the name of the iteration where all team members determine how much of the team's backlog they can commit to delivering during an upcoming iteration?

Backlog Refinement

How often should a system demo occur?

Every Iteration (2 weeks)

Which activity is the Scrum Master's Responsibility?

Coaching the Agile Team

How many team members make up an Agile Team?

5-9 members

ScrumXP

A lightweight process for self-organizing and self-managing cross-functional teams of five to nine people. To continuously value, _______ uses the Scrum framework for project management and XP-derived software engineering practices.

Team Kanban

Is a Lean method that helps teams facilitate the flow of value by visualizing workflow, establishing Work in Progress (WIP) limits, measuring throughput, and continuously improving their processes.

Who has content authority for the Team Backlog?

Product Owner

Who is responsible for defining stories and prioritizing the backlog?

Product Owner

What are the 3 purposes of a Scrum Master?

Remove impedimentsFacilitates Team eventsFosters an environment for high-performing teams

Team PI Objectives

Are a summarized description of the specific business and technical goals that an Agile team intends to achieve in the upcoming PI. Often map to features but not always.

Exploration Enablers

These support research, prototyping, and other activities needed to develop an understanding of Customer needs, including the exploration of prospective Solutions and evaluating alternatives.

Architectural enablers

These are created to build the Architectural Runway, which allows smoother and faster development

Infrastructure enablers

These are created to build, enhance, and automate the development, testing, and deployment environments. They facilitate faster development, higher-quality testing, and a faster Continuous Delivery Pipeline

Compliance enablers

These facilitate managing specific compliance activities, including Verification and Validation (V&V), documentation and signoffs, and regulatory submissions and approvals

Agile development is...

incremental

____________ over processes and tools

Individuals and interactions

Working software over...

comprehensive documentation

Customer collaboration over...

contract negotiation

_____________ over following a plan

Responding to change

Agile Manifesto

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

Agile Manifesto Principles 1-6

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale4. Business people and developers must work together daily throughout the project (Have a role for business sides, then roles for IT. Show your work, transparency builds trust)5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done6. The most efficient and effective method of converying information to and within a development team is face-to-face conversation

Transparency builds...

trust

Agile Manifesto Principles 7-12

7. Working software is the primary measure of progress8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely 9. Continuous attention to technical excellence and good design enhances agility10. Simplicity - the art of maximizing the amount of work is not done - is essential11. The best architectures, requirements, and designs emerge from self-organizing teams12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (Retrospective "retro"; reuse/revision)

Develop on cadence...

Release on demand

Agile is value...

and quality driven

Agile teams show that ______ matter

dates

Business owners show how __________ matter

priorities

Fix _______, not scope

quality

Backlog is NOT a...

commitment

Agile practices

TimeboxingUser storiesDaily stand-upsFrequent demosTest-driven developmentInformation radiatorsRetrospectivesContinuous integration

Timeboxing

a technique that delivers information systems functionality and requirements through versioning.

Scrum involves...

planning

Kanban involves less...

planning, more of a reaction. Filling people's queues based on capacity.

What is the single most important component for ensuring the success of the program?

The Scrum Master

SAFe recommends ______/_________ involved in every demo

clients/consumers

Scrum Values

CourageCommitmentFocusRespectOpenness

Iteration length is...

one to four weeks

What is the SAFe recommendation for the length of an iteration?

2 weeks (small batch size)

Goal is to deliver ________ ___________/___________ at the end of each iteration

working software/hardware

Avoid adding _____ once the iteration has begun

scope

Team Backlog

Represents opportunities, not commitments. Is created by the Agile Team.Is owned and prioritized by the team's Product Ownercontains user and enabler stories

Backlog refinement (timebox/value?)

~1 hrPrepare requirements for Iteration Planning

Iteration Planning (timebox/value?)

2 - 4 hrsTeam commits to a set of goals to be delivered in the Iteration

Daily Stand-up (timebox/value?)

<= 15 minutesTeam members sync regarding the progress of the Iteration Goals

Iteration Review (timebox/value?)

~1 hrDeliverables reviewed with stakeholders providing feedbackAlso the demo, all attend.

Iteration retrospective (timebox/value?)

1 - 1.5 hrsTeam reviews and improves its process before the next iteration. Attendees - Agile Team only.

___ facilitates the Scrum-of-Scrum

RTE

Scrum Master Characteristics

Coaches team improvement using values, principles, and best practicesFacilitates Scrum team eventsProtects the development teamHelps to remove impedimentsIs a servant leader (an optimizer, groups people, supports members. Figure out ways to help others improve.)Interact w/ people on a one-to-one basis. Help them along the way

Product Owner Characteristics

The single voice of the customer and stakeholders in the teamOwns and manages the Team Backlog (prioritizes it)Defines and accepts requirements (builds quality w/in the team)Makes the hard calls on scope and content

Development Team Characteristics

Typically 3-9 people (excluding Scrum Master and Product Owner)Everyone who is needed to define, build, and testTeam members are only on this teamSelf-organizing and accountableCollaborativeCross-functionalEmpowered (sometimes have to protect team from PO and even from SM. Have to learn to let people fail, when it is safe to fail)

Development Team Responsibilities

Listen and talk to peopleSeek and accept helpEmbrace changeWork on items in an order set by the POBe proactive and self-motivatedBe honest (w/ yourself and others)Be passionate about what you doEmbrace "all sink or swim"Everyone involved shares the risks. Make sure you are transparent

SAFe Core Values

- Alignment- Transparency- Built-in Quality- Program Execution

SAFe Lean-Agile Principles (9 total)

1. Take an economic view2. Apply systems thinking3. Assume variability; preserve options4. Build incrementally with fast, integrated learning cycles5. Base milestones on objective evaluation of working systems6. Visualize and limit WIP. Reduce batch sizes. Manage queue lengths7. Apply cadence, synchronize w/ cross-domain planning8. Unlock the intrinsic motivation of knowledge workers9. Decentralize decision-making10. Organize around value

A "feature" is a collection of _______

storiesFits one PI for one ARTIncludes acceptance criterialarger system behaviors that fulfill user's needsPlain language (not tech speak)

Agile Release Train

a virtual organization of 5-12 teams (50-125+) that plans, commits, and executes together- Aligns team to a common business and technology mission to deliver a continuous flow of value.

A _______ _________ (__) is a fixed timebox; default is 10 weeks

Program Increment (PI)

Agile release train

Define new functionalityImplementAcceptance testDeploy

ART Roles: Release Train Engineer (RTE)

acts as the Chief Scrum Master for the train

ART Roles: Product Management

owns, defines and prioritizes the Program Backlog.

ART Roles: System Architect/Engineering

provides architectural guidance and technical enablement to the teams on the train

ART Roles: System Team

provides processes and tools to integrate and evaluate assets early and often

ART Roles: Business Owners

are the key stakeholders on the Agile Release Train

Program Events for the ART

PI PlanningART SyncSystem DemoInspect and Adapt event

ART Program Events: PI Planning

Timebox: 2 days, every 8-12 weeks (10 weeks ave)Value: Teams commit to a set of objectives to be delivered in the PI

ART Program Events: ART Sync

Timebox: 1 hrValue: train teams to sync regarding the progress of the PI

ART Program Events: System Demo

Timebox: 2 hrsValue: deliverables reviewed with stakeholders providing feedback

ART Program Events: Inspect and Adapt event

Timebox: 1/2 dayValue: The train reviews and improves its process before the next PI1) PI System Demo2) Quantitative measurements3) Problem-solving workshopAttendees: Teams/stakeholdersLed: PO, PM and System TeamsEnd - planned vs. actual business value )BV) rolled up to program predictability measure.

SPC

SAFe Program Consultant

1 Increment equals...

... 5 iterations

For a large solution, how many people can be on one ART?

50 to 125

The 5th sprint is the...

Innovation and planning sprint. Sometimes lasts 3 weeks. Sometimes works to have a longer time. Need to build in flexibility in your cadence

How a Scrum Master supports and Agile Team

Coaches the team to create better Solutions, improve business results, and better their processesFacilitates team and program eventsRemoves impediments to the team's progressAssists the team in implementing SAFe and working with other teams who may or may not be using SAFeFosters adoption of Agile technical practicesAssists the PO in preparing and refining the backlog for PI and Iteration PlanningCoaches the team on the best ways to refine their backlog and create Stories

The Scrum Master is the great ________

optimizer

Ensure demos are _________. Strive for _________ code.

integrated

How to be a servant leader (DW p45)

Listens and supports team members in problem identification and decision-makingUnderstands and empathizes with othersEncourages and supports the personal development of each individualPersuades rather than uses authorityThinks beyond day-to-day activitiesLooks to help without diminishing the commitment of othersCoaches the team on Agile best practices

What makes up PI Planning?

2 days every 8-12 weeks (10 weeks is typical) - all members should be involvedEveryone attends in person if at all possibleProduct Management owns Feature prioritiesDevelopment teams own Story planning and high-level estimatesArchitect/Engineering and UX work as intermediaries for governance, interfaces, and dependencies

A benefit hypothesis...

justifies feature implementation cost and provides business perspective when making scope decisions

User Story Guidelines (the 3 Cs)

Card - written on a card or in the tool and may annotate with notesConversation - the details are in a conversation with the Product Owner (PO)Confirmation - Acceptance criteria confirm the Story correctness

User story template

As a <user role>, I want to <activity> so that <business value>.

Acceptance Criteria

Provide the details of the Story from a testing point of viewAre created by the Agile TeamExpress the conditions that need to be satisfied for the customer (acceptable behavior)Provide context for the team, more details of the Story, and help the team know when they are doneAre written by the customer/PO and refined by the team during backlog refinement and Iteration planningUse User Acceptance Test Scenarios typically as a starting point

Advantages of Acceptance Criteria

Continue the conversation between the PO and the teamHelps solidify expectations for the StorySpawns negotiation, trade-offs, and options to split a large Story into smaller StoriesEstablishes a high-level test planProvides a basis for Solution design

Acceptance Criteria Formats

Test that <criteria>Demonstrate that <this happens>Verify that when <a role> does <some action> they get <this result>Given <a context> when <this event occurs> then <this happens>

How much acceptance criteria?

Stop when:You have enough to size the storyTesting will become to convolutedYou have made 2-3 revisions of the criteria

INVEST Acronym (in a good User Story)

IndependentNegotiableValuableEstimableSmallTestable

Enabler Stories

Can represent different types of work: Exploration, Architecture, Infrastructure.Demonstrated just like any other StoryEnables functional value by another future storyDon't deliver actual business value

Types of Enablers

Spikes and Refactors

Refactors

Systematic approach to improving the system without changing observable system behaviorExample: improving maintainability, performance, or scalability

A Story Point is a singular number that represents:

Volume: how much is there?Complexity: how hard is it?Knowledge: what do we know?Uncertainty: What's not known?

SM's role in facilitating estimations

Make sure everyone participatesEnsure relative estimates are usedFocus the discussion on contested itemsKeep time spent estimating Stories to a minimumIdentify SMEs who need to be present

Common anti-patterns for estimations

Pressure by stakeholders to lower estimationsOnly a few people participateNot using the adjusted Fibonacci scale

Normalized estimation technique

For every full-time developer and tester on the team, give the team 8 pts (adjust for part-timers)Subtract 1 point for every team member vacation day and holidayFind a small Story that would take about a half-day to develop and a half-day to test and validate, and call it a 1Estimate every other Story relative to that oneNever look back (don't worry abut recalibrating)

PI Planning Briefing Typical Schedule

RTE Facilitates the PI Planning event and kicks off the briefingsThe executive, Product Manager, System Architect/Development Manager/UX role conduct their briefings to the entire ARTThe RTE briefly reviews the purpose of the meeting (alignment) and presents the agenda, planning guidance, and planning requirementsThe executive presents the business context slidesPM presents Vision and Feature and Benefits slidesSystem Architect/Dev Manager/UX role presents the Architecture, UX, and Developer manager briefing slides

Management Review and Problem-Solving

At Day 1 end, management meets to make adjustments to scope and objectives based on the day's planning.During Inspect & Adapt event.Scrum Master's role (p153)

Common questions during Managers' Review Session

What did we just learn?Where do we need to adjust Vision? Scope? Resources?Where are the bottlenecks?What Features must be de-scoped?What decisions must we make between now and tomorrow to address these issues?

Possible changes that result from Manager's Review

Business prioritiesAdjustment to planChanges to scopeMovement of people

ROAM Risks - Addressing program risk

Resolved - has been addressed; no longer a concernOwned - someone has taken responsibilityAccepted - nothing more can be done. If risk occurs, release may be compromised.Mitigated - team has plan to adjust as necessary

Confidence Vote

Teams agree to do everything in their power to meet the agreed-to objectivesIn the event that fact patterns dictate that it is simply not achievable, teams agree to escalate immediately so that corrective action can be taken1 - no confidence2 - little confidence3 - good confidence4 - high confidence5 - very high confidenceAnyone who puts up a 1/2 is asked to speak. They may have a risk that was not previously considered. Goal is to have everyone at a 3 or above. Encourage everybody to speak up. This helps build further trust

Goals to review during a Retrospective Meeting

1. What went well2. What didn't3. What we can do better next time

Scrum Master's role in team breakout #1

Ensure team has a draft plan to presentIdentify as many risks and dependencies as possible for the management reviewSecure subject matter experts and Program Level stakeholders as needed by the teamFacilitate the coordination with other teams for dependencies

Common Anti-Patterns for team breakout #1

- No plan or partial plan at the end of the timebox.- Too much time is spent analyzing each story- Shared Scrum Masters and Product owners are not available enough- Part-time scrum masters don't have time to plan as part of the team

Scrum Master's Role in PI Planning

- Maintain the timebox- Make sure the team builds a plan they can commit to- Ensure that the team is honest in their confidence vote- Facilitate the coordination with other teams, but don't do it FOR the team- Act as a request buffer for a team that has a lot of dependencies - Manage the program boardFacilitate the retrospective

Common anti-patterns in PI Planning

Pressure is put on the team to overcommitTeam under commits due to fear of failureOver-planning ahead of time to make it more efficient loses the essence of PI PlanningThe plan, rather than the alignment, become the goal

Goals

Help align team, determine quality levels, risk mitigation at its core. They provide flexibility

Iteration Planning Flow

-Establishing capacity- Story analysis & estimation- Detailing Stories- Developing iteration goals- Committing to iteration goals- Continues until estimation of stories reaches capacity of team

Iteration Goals

Provide clarity, commitment (other teams, the program and stakeholders) and management information.Serve 3 purposes:1. Align team members to a common purpose2. Align Agile teams to common PI Objectives and manage dependencies3. Provide continuous management information-Commitment/adaptability

A common approach is to _____ _______ into _____ during Iteration Planning

split stories ____ tasks

Scrum Master's role in Iteration Planning

- Maintain timebox- Ensure that the team commits to the Iteration GoalsVerify that the PO or other managers don't influence the team to overcommit- Challenge the team to exceed their previous accomplishments- Ensure that improvement items from the retrospective are put into effect- Ensure time is allocated for technical debt activities

Common anti-patterns in Iteration Planning

Delving too deep into technical discussionsCommitment is unrealisticVelocity and load are exactly the sameScrum Master is more focused on technical hat than facilitator's hatThe team under-commits due to fear of failureNo time is reserved for support activities

5 dysfunctions of a team & help for each (DW p61-63)

1) absence of Trust - safe environment2) Fear of Conflict - SM encourages disagreements3) Lack of Commitment - shared commitment to each other/external stakeholders4) Avoidance of Accountability - stakeholders, peer pressure & review of results5) Inattention to Results - review at end of IP and release.

Resolving Conflict (DW p65)

1) Working Agreements2) Achieving consensus

Agile Teams

- Cross-functional, self-organizing entities Create and refine User Stories and acceptance criteria - Define, build, test, and deliver Stories- Develop and commit to team Pl Objectives and Iteration plans - Five to eleven members - Plan their work at periodic, largely face-to-face PI Planning events

Product Owner

- Defines and accepts Stories - Acts as the Customer for developer questions -Works with Product Management to plan Program Increments (Pl)

Built-in Quality Practices

Lean and Agile principles & practicesBehavior-driven development (BDD)eXtreme Programming (XP)Code qualityDesign patterns and practicesAgile modeling

ART Events

- PI Planning - 2 days - teams commit to set of objectives- ART Sync - 1 hr - regarding progress of PI- System Demo - 2 hr - review with stakeholders for feedback- Inspect & Adapt - 4 hour - review and improves its process before next PI

Common attributes of high-performing teams

► Self-organizing ► Understand work's impact on organization ► Effective decision-making ► Aligned and collaborative ► Open and clear communication ► Safe atmosphere to take risks ► Valued diversity ► Effective timely feedback ► Mutual trust ► Sufficient resources for local control ► Healthy conflict ► Success focus over failure avoidance ► Clear goals and purpose ► Abilities balanced with challenge ► Concentration and focus ► Engagement ► Fun with work and each other ► Ownership and accountability

Stages of high-performing teams

Forming, storming, norming, performing, adjourning

Challenge with meetings

Meetings can be challenging because: - The purpose is not clear - There are no actionable outcomes - They may result in unproductive conflict - They may be boring - Conversation may divert from the agenda to deep discussion ► Such meetings add almost no value ► Ineffective meetings can (and should) be fixed

Running Successful Meeting (1 of 2)

► Prepare for every meeting , no matter how short ► Communicate a clear purpose and agenda ► Identify a directly responsible individual (ORI) for maintaining agenda/action items ► Expect participants to know why they are attending , what contributions they will make, and expected outcomes ► Leave with clear action items ► Promote and keep to timeboxes ► Be prepared to challenge and be challenged ► Get participants moving and ensure active engagement

Running Successful Meeting (2 of 2)

► Establish default decisions-decisions should never wait for a meeting ► Don't bring a problem without bringing at least one possible solution ► Review actions taken to meet commitments-enforce accountability ► Use "Yes, and ..." instead of "No, but ... " to keep inputs positive and flowing ► Take frequent breaks ► Go the extra mile to bring remote participants into the discussion ► Maintain communication beyond the meeting

Powerful questions (DW p54-56)

though-provoking, generate curiosity, channel focus, generate energy, stimulate reflective conversation, surface underlying assumptions, invite creativity, inspire questions, reach deep meaning.

Scrum of Scrums (SoS) Meeting

For Scrum Masters and the RTE to gain visibility into team progress and program impediments, 2x week.

User Stories are:

Short descriptions of a small piece of desired functionality, written in the user's languageRecommend form of expression is the user-voice

Persona

Detailed fictional characters acting as a representative user.

Acceptance Test

Derive from acceptance criteriaDefine specific pass/fail behavior

Estimating Poker

Combines expert opinion, analogy, and disaggregation for quick reliable estimates (Story points)Includes whole teamBuilds understandingShared commitment

Velocity

Sum of pts for all completed stories that met Definition of Done (DoD)Use output from last iteration, if possible.

Uncommitted Objectives

Identify work that can be variable within the scope of PI. Only if time permits within the PI.

Planning Guidance

- Product Owners: You have the content authority to make decisions at the user Story level - Scrum Masters: Your responsibility is to manage the timebox, the dependencies, and the ambiguities - Agile Team: Your responsibility is to define users Stories, .... plan them into the Iteration, and work out interdependencies with other teams

Daily Stand up Patterns (DSU)

- Yesterday's accomplishments- Today's accomplishments- Any roadblocks impeding on iteration goals?

Daily Stand-up (Meet-after agenda)

- review topics SM wrote on Meet-after board- Involve parties discuss. Others leave.

BVIR

Big Visible Information Radiator (team board to track progress) during DSU. Tracks iteration progress.

Iteration burn-down chart

- Count remaining efforts- Focus on tasks completed vs stories completed- Hard to distinguish between work added and not done

Work In Progress (WIP) limits

Improve work. Some steps, no limit, other serve as buffer with min/max.

Scrum Master's role in tracking Iteration progress

- Facilitate mid-Pl re-planning - Encourage the team to point out as early as possible if they think they will miss Iteration goals or Pl Objectives . - Communicate to and from the scrum of scrums - Encourage the use of engineering practices - Make sure defects are not pushed to the IP Iteration - Facilitate preparation for the next Pl - Support release activities

Scrum Master's role in Backlog Refinement

- Maintain timeboxes - Maintain the right level of a deep backlog vs ready backlog for two Iterations - Make sure all the team members participate - Invite the right subject matter experts - Hold the event at regular intervals

Scrum Master's Role in Team/System Demo

- Begin to consider how and what to demo in Iteration Planning - Make sure the right participants are present - Ensure that the team celebrates its accomplishments and that stakeholders acknowledge them - Make sure different team members have the opportunity to demo - Ensure that the team is ready for the System Demo and coordinates with the System Team

Iteration Metrics

# stores, # accepted stories, % accepted, # not accepted, # pushed to next Iteration, # deferred, # deleted, # added.

DevOps (Speed & Stability together)

C- Culture (shared responsibility)A - Automation (Cont. delivery pipeline)L - Lean flow (Batch size small, limit WIP, visibility)M - Measurement (flow thru pipeline.)R - Recovery ( implement low risk releases, fast recovery/reversions/fix-forward)Operations, development, security, architecture, Business, Compliance