1. Scrum Artifacts
1.1. Definition
1.1.1. Scrum’s artifacts represent WORK or VALUE to provide TRANSPARENCY and opportunities for INSPECTION and ADAPTATION.
1.1.2. is designed to maximize transparency of key information so that everybody has the same understanding of the artifact
1.2. Product Backlog
1.2.1. is the single source of requirements to make the products
1.2.2. WHO
1.2.2.1. Product Owner
1.2.2.1.1. content
1.2.2.1.2. availability
1.2.2.1.3. ordering
1.2.3. PB attributes
1.2.3.1. evolves as the product & environment
1.2.3.2. is dynamics
1.2.3.3. be changed to identify PO's needs to be
1.2.3.3.1. appropriate
1.2.3.3.2. competitive
1.2.3.3.3. useful
1.2.3.4. exists as product exists
1.2.3.5. list all
1.2.3.5.1. features
1.2.3.5.2. functions
1.2.3.5.3. requirements
1.2.3.5.4. enhancements
1.2.3.5.5. fixes
1.2.3.6. PB ITEMS
1.2.3.6.1. descriptions
1.2.3.6.2. order
1.2.3.6.3. estimate
1.2.3.6.4. value
1.2.4. Is a living artifact
1.2.5. Can be changed by
1.2.5.1. business requirements
1.2.5.2. market condition
1.2.5.3. technology
1.2.6. Multiple Scrum Team works on 1 product share ONE PB
1.2.7. PB Refinement
1.2.7.1. is the act of adding detail, estimates, and order to items in the PB
1.2.7.2. PO and Dev team collaborate to refine PB
1.2.7.3. Scrum TEAM define how & when refinement is done
1.2.7.4. consume max 10% capacity of DEV TEAM
1.2.8. Be updated any time by PO
1.2.9. DEV TEAM responsible for all estimation
1.2.9.1. PO can help Dev team to understand & select trade-offs
1.3. Monitoring Progress Toward a Goal
1.3.1. Practices
1.3.1.1. Burn down
1.3.1.2. Burn up
1.3.1.3. cumulative flows
1.3.2. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making.
1.4. Sprint Backlog
1.4.1. selected PB items for a sprint + plan for delivering increments
1.4.2. is a forecast by Dev team about what's the next increment to be done + the work needed
1.4.3. makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.
1.4.4. is a plan with enough details that changes in progress can be understood in Daily scrum
1.4.5. is modified during Sprint by Dev team
1.4.6. is emerged during sprint
1.4.6.1. emergence is the work needed to achieve Sprint Goal
1.4.6.2. as new work is required, Dev team add them to Sprint Backlog
1.4.6.3. unnecessary element of plan is removed by Dev team
1.4.7. WHO
1.4.7.1. belongs solely to DEV TEAM
1.4.7.2. Only DEV team can change its SB during sprint
1.5. Monitoring Sprint Progress
1.5.1. DEV TEAM tracks total of remaning work for every Daily scrum
1.5.2. DEV team manages its progress by tracking & forecasting Sprint Goal achievement
1.6. Increment
1.6.1. Is the sum of
1.6.1.1. all completed PB item in a sprint
1.6.1.2. value of increments of previous sprints
1.6.2. At the end of sprint, increment must be DONE
1.6.2.1. in usable condition
1.6.2.2. meets Scrum team's defenition of DONE
1.6.2.3. It must be in useable condition regardless of whether the Product Owner decides to actually release it.
2. Scrum Events
2.1. Scrum Events
2.1.1. are timeboxed
2.1.2. every event has a maximum duration
2.1.3. its duration is fixed
2.1.4. remaining events may end whenever its purpose is achieved
2.1.5. are formal opportunity to inspect OR adapt smt
2.1.6. failure: reduce transparency, lost above opportunities
2.2. Sprint
2.2.1. 1 month maximum
2.2.2. Done, Usable, Potentially releasable Prd increment
2.2.3. New spr starts immediately after conclusion of the previous spr
2.2.4. Contains:
2.2.4.1. Sprint planning
2.2.4.2. Daily meeting
2.2.4.3. Development work
2.2.4.4. Sprint review
2.2.4.5. Sprin retrospective
2.2.5. During sprint
2.2.5.1. No change made that endanger Sprint Goal
2.2.5.2. Quality do not decrease
2.2.5.3. Scope can be clarified and re-negotiated between PO and Dev team AS more is LEARNED
2.2.6. Each Sprint has
2.2.6.1. definition of what to be built
2.2.6.2. a design
2.2.6.3. flexible plan
2.2.7. One month maximum
2.2.7.1. limit risk of cost to 1-month cost
2.2.7.2. enables predictability by ensuring inspection & adaptation of progress toward Sprint Goal
2.2.8. Too long
2.2.8.1. definition of what's being built may change
2.2.8.2. complexity may rise
2.2.8.3. risk may increase
2.2.9. Cancelling a sprint
2.2.9.1. WHEN? can be cancelled before time-box is over
2.2.9.2. WHO?: Only PO has the authority ( although this may be under influence of
2.2.9.2.1. Dev team
2.2.9.2.2. SM
2.2.9.2.3. Stake holders
2.2.9.3. WHY?
2.2.9.3.1. Sprint goal becomes obsolete
2.2.9.3.2. It no longer makes sense given the circumstance
2.2.9.4. EFFECT?
2.2.9.4.1. rarely makes sense because Sprint duration is short
2.2.9.5. What to do?
2.2.9.5.1. review all Done & complete product backlog items
2.2.9.5.2. undone pb items are re-estimated and put back to product backlog
2.2.9.6. Consequence
2.2.9.6.1. consume resource
2.2.9.6.2. re group team
2.2.9.6.3. re plan new sprint
2.3. Sprint Planning
2.3.1. to plan the work to be performed in Sprint
2.3.2. this plan is created by collaborative work of SCRUM TEAM
2.3.3. maximum 8hs - one month Sprint
2.3.4. SM
2.3.4.1. ensure S-planning takes place
2.3.4.2. people understands its purpose
2.3.4.3. teach people to keep it within timebox
2.3.5. TWO Questions
2.3.5.1. What can be done this Sprint?
2.3.5.1.1. Dev team forecast functionalities to be developed
2.3.5.1.2. PO discusses objective of sprint and product backlog items (if completed in the Sprint)
2.3.5.1.3. Entire team collaborate to understand the works of the sprint
2.3.5.1.4. Input:
2.3.5.1.5. Selected items from Product backlog is SOLELY UP TO DEV TEAM
2.3.5.1.6. Output:
2.3.5.2. How will the work get done?
2.3.5.2.1. decided by Dev team
2.3.5.2.2. usually start by designing the system & the work needed
2.3.5.2.3. enough work is planned to forecast what it believes it can do in the upcoming Sprint
2.3.5.2.4. work for the first day of sprint is decomposed at the end of Spr planning
2.3.5.2.5. Dev team and PO can negotiate to have suitable work
2.3.5.2.6. Dev team can invite other people for advise ( SME, TL...)
2.3.5.2.7. In the end: explan to PO and SM how it intends to work as self-organize team to accomplish the Sprint Goal and create the anticipated Increment.
2.4. Daily Scrum
2.4.1. 15mins timeboxed
2.4.2. to synchronize activities and create plan for next 24h
2.4.3. held at same time & place to reduce complexity
2.4.4. Dev team members answer 3 question
2.4.4.1. what did I do yesterday
2.4.4.2. what will I do today
2.4.4.3. any impediment to me or Dev team
2.4.5. to inspect progress toward sprint goal
2.4.6. to inspect how progress is trending toward completing works in Sprint backlog
2.4.7. team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work
2.4.8. SM makes sure Scrum team has Daily Scrum
2.4.9. SM teaches Dev Team to keep timebox 15mins
2.4.10. SM enforces rule: Only Dev team member participates in Daily Scrum
2.4.11. Dev Team responsible for conducting Daily Scrum
2.4.12. IMPROVE:
2.4.12.1. communication, eliminate other meetings
2.4.12.2. Dev team's level of knowledge
2.4.13. IDENTIFY:
2.4.13.1. Impediments
2.4.13.2. highlight, promote quick decision making
2.4.14. IS A KEY INPECT AND ADAPT MEETING
2.5. Sprint Review
2.5.1. WHEN:
2.5.1.1. is held at the end of the sprint
2.5.1.2. this is an informal meeting
2.5.2. DO WHAT
2.5.2.1. to inspect the increment
2.5.2.1.1. collaborate about what was done in the sprint
2.5.2.2. to adapt Product Backlog if needed
2.5.2.2.1. collaborate on next things that could be done to optimize value
2.5.2.3. presentation of the Increment is intended to elicit feedback and foster collaboration
2.5.3. WHO
2.5.3.1. Scrum team
2.5.3.2. Stakeholders
2.5.4. 4 hours Timeboxed for 1 month sprint
2.5.5. SM ensures
2.5.5.1. the event takes place
2.5.5.2. attendees understand its purpose
2.5.5.3. teach all to keep it within timebox
2.5.6. ELEMENTS
2.5.6.1. PO invites Scrum Team & Stakeholders
2.5.6.2. PO explains Done & notDone prd backlog items
2.5.6.3. Dev Team discusses
2.5.6.3.1. what went well
2.5.6.3.2. what's problem
2.5.6.3.3. how they solved problem
2.5.6.4. Dev Team demos "Done" work & answer questions about increment
2.5.6.5. PO discusses Prd backlog & forecast completion date based on current progress
2.5.6.6. Entire group works on what to do next
2.5.6.6.1. INPUT for next SPRINT PLANNING
2.5.6.7. Review marketplace, potential use of prd... is the most valuable thing to do next
2.5.6.8. Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release
2.5.7. OUTPUT
2.5.7.1. a revised Product Backlog that defines the probable Product Backlog items for the next
2.5.7.2. The Product Backlog may also be adjusted overall to meet new opportunities
2.6. Sprint retrospective
2.6.1. DO WHAT
2.6.1.1. Scrum team inspect itself
2.6.1.2. create plan for improvement to be done in next sprint
2.6.2. WHEN
2.6.2.1. after sprint review
2.6.2.2. prior to next Sprint planning
2.6.3. 3-hour timeboxed for 1 month sprint
2.6.4. PURPOSE
2.6.4.1. Inspect how the last Sprint went with regards to
2.6.4.1.1. People
2.6.4.1.2. Relationship
2.6.4.1.3. Process
2.6.4.1.4. Tools
2.6.4.2. Identify & order the major items that went well and potential improvements;
2.6.4.3. create plan for implementing improvements which is done by Scrum team
2.6.5. SM ensures
2.6.5.1. the event takes place
2.6.5.2. attendees understand its purpose
2.6.5.3. teach all to keep it within timebox
2.6.5.4. participates as a peer team member
2.6.6. SM Encourage team
2.6.6.1. improve its development process (within Scrum framework)
2.6.6.2. practice to make development process
2.6.6.2.1. more effective
2.6.6.2.2. more enjoyable
2.6.7. SCrumTeam
2.6.7.1. plan way to increase product quality by adapting definition of Done as appropriate
2.6.8. OUTPUT
2.6.8.1. identified improvements to be implemented in the next sprint
2.6.8.1.1. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself.
2.6.8.1.2. improvements may be implemented at any time
3. The Scrum Team
3.1. The Scrum Team
3.1.1. Consist of
3.1.1.1. Product Owner
3.1.1.2. Development Team
3.1.1.3. Scrum Master
3.1.2. Self-organizing
3.1.2.1. choose HOW best to accomplish the work
3.1.3. Cross functional
3.1.3.1. have all competencies to accomplish the work without depending on others not part of the team
3.1.4. This model is design to optimize
3.1.4.1. Flexibility
3.1.4.2. Creativity
3.1.4.3. Productivity
3.1.5. Deliver product iteratively & incrementally
3.1.5.1. maximizing chance for feedbacks
3.1.6. Ensure the potentially useful version of working product is always available
3.2. The Product Owner
3.2.1. responsibility
3.2.1.1. maximizing value of product
3.2.1.2. maximizing the work of the team
3.2.2. is a sole person
3.2.3. manage Product backlogs
3.2.3.1. clearly expressing product backlog items
3.2.3.2. ordering the product backlog items (prioritizing )
3.2.3.3. optimizing the value that Dev team performs
3.2.3.4. ensure product backlogs are visible, transparent and clear to all
3.2.3.5. show what Dev team will work on next
3.2.3.6. ensure Dev team understands product backlogs to the level needed
3.2.4. Priority of product backlog can only be changed by Product owner
3.2.5. Organization must respect Product owner's decisions (content and ordering of Product backlogs)
3.3. The Development Team
3.3.1. Untitled
3.3.2. are structured and empowered by the organization
3.3.3. Dev team only works on a specific set of requirements , BUT, never own a PBI
3.3.4. do the work of delivering a potentially releasable Increment of Done at the end of each Sprint
3.3.5. organize & manage their own work
3.3.6. Characteristics:
3.3.6.1. self-organizing
3.3.6.2. are cross-functional
3.3.6.3. Tittle: Developers
3.3.6.4. no sub-team in Dev Team
3.3.6.5. accountability belongs to the whole team
3.3.7. Team size
3.3.7.1. <3 : decrease interaction & result; may encounter skills constrains during sprint
3.3.7.2. >9: require too much coordination , generate complexity
3.3.7.3. PO and SM are not included , unless they executing the work of Product Backlog
3.4. The Scrum Master
3.4.1. Responsible for ensuring Scrum is understood and enacted , Scrum Team adheres to Scrum rules, practices, theory.
3.4.2. HELP OTHERS OUTSIDE understand helpful & unhelpful result of their interactions
3.4.3. HELP EVEYRONE change these interaction to maximize value created by Scrum Team
3.4.4. SM service PO
3.4.4.1. find technique for effectively manage product backlog
3.4.4.2. help Scrum Team understand the need for clear and concise PB items
3.4.4.3. Understanding product planning in an empirical environment;
3.4.4.4. Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value
3.4.4.5. Understanding and practicing agility; and,
3.4.4.6. Facilitating Scrum events as requested or needed
3.4.5. SM service to Dev team
3.4.5.1. Coaching the Development Team in self-organization and cross-functionality
3.4.5.2. Helping the Development Team to create high-value products
3.4.5.3. Removing impediments to the Development Team’s progress
3.4.5.4. Facilitating Scrum events as requested or needed; and
3.4.5.5. Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
3.4.6. SM service to Organization
3.4.6.1. LEAD & COACH org in its Scrum adoption
3.4.6.2. PLAN Scrum implementations within the organization
3.4.6.3. HELP employees and stakeholders understand and enact Scrum and empirical product development;
3.4.6.4. CAUSE change to increase Scrum team's Productivity
3.4.6.5. WORK with other SM to increase effectiveness of application of Scrum in org
4. Definition of Scrum
4.1. Is a framework
4.2. people can address complex adaptive problems
4.3. deliver product with highest possible value
4.4. inlude:
4.4.1. Scrum team
4.4.2. Roles
4.4.3. Events
4.4.4. Artifacts
4.4.5. Rules
5. Scrum Theory
5.1. Scrum is founded on empirical process control (empiricism)
5.2. Transparency
5.2.1. significant aspects of the process must be visible to those responsible for the outcome
5.2.2. aspects are defined by a common standard, all observers share the same understanding
5.2.3. dev and approver share the same definition of done
5.3. Inspection
5.3.1. Scrum users must frequently inspect Scrum artifacts & progress comparing with Sprint goal --> detect undesirable variances.
5.3.2. Inspections should not be too frequent
5.3.3. most beneficial when being performed by skilled inspector at the point of the work
5.4. Adaptation
5.4.1. An inspector determines that an aspect of process deviate outside acceptable limits, leading the result be unacceptable , that process must be adjusted.
5.4.2. An adjustment must be made as soon as possible to minimize further deviation
5.4.3. 4 formal events for inspection and adaptation
5.4.3.1. Sprint planning
5.4.3.2. Daily scrum
5.4.3.3. Sprint review
5.4.3.4. Sprint retrospective
6. Definition of Done
6.1. What is done?
6.1.1. a Product backlog item
6.1.2. an increment
6.2. vary significantly per Scrum Team
6.2.1. all members must have a shared understanding of what it means for work to be complete, to ensure transparency
6.2.1.1. is definition of "Done" for Scrum team
6.2.1.2. is used to assess when work is complete on the product Increment.
6.3. guide Dev team in knowing how many Product Backlog items it can select during a Sprint Planning
6.4. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s CURRENT definition of “Done.”
6.5. DEV team delivers an increment everysprint, it is USABLE, PO can choose to immediately release it
6.6. definition of Done for an increment& conventions, standards or guidelines of the development organization
6.6.1. IS: All Scrum team must follow as a minimum
6.6.2. NOT: Scrum team define DOD appropriate for the product
6.7. Multiple Scrum Team working on same product, the DEV team on ALL scrum team must mutually define DOD
6.8. Each increment is additive to all prior increments & tested, ensuring ALL Increments work together
6.9. As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more STRINGENT criteria for higher quality.
6.10. Any one product or system should have a definition of “Done” that is a standard for any work done on it.
7. Artifacts Transparency
7.1. Scrum relies on Transparency
7.2. Decisions to optimize value and control risk
7.2.1. are based on perceived state of artifacts
7.2.2. have sound basis (GOOD) if transparency is complete
7.2.3. be flawed, value may diminish and risk may increase (BAD) if artifacts are incompletely transparent
7.3. Scrum Master must work with ... to understand if artifacts are completely transparent
7.3.1. Product owner
7.3.2. Development Team
7.3.3. involved parties
7.4. Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency
7.5. Scrum Master detects incomplete transparency by
7.5.1. inspecting artifacts
7.5.2. sensing patterns
7.5.3. listening closely to what's being said
7.5.4. detecting differences between Expected & real Results
7.6. Scrum Master works with
7.6.1. Scrum Team
7.6.2. Organization
7.6.3. to increase the transparency of artifacts
7.6.4. including
7.6.4.1. learning
7.6.4.2. convincing
7.6.4.3. change