Please enable JavaScript.

Coggle requires JavaScript to display documents.

SCRUM (Overview (is (NOT (process, technique, definitive method),…

- - - - address complex adaptive problems
      - while productively and creatively delivering products of the highest possible value.
  - - - process
      - technique
      - definitive method
  - - - techniques
      - processes
  - - - product management
      - work techniques
    - - Product
      - Team
      - Working environment
  - - - Roles
      - Events
      - Artifacts
      - Rules
  - - - roles
      - events
      - artifacts
      - governing the relationships and
        interaction between them
- - - - software
      - hardware
      - embedded software
      - network interacting function
      - autonomous vehicles
      - schools
      - government
      - marketing
      - managing the operation of organizations
      - almost everything we use in our daily lives
        
        individuals
        
        socities
  - - - as many times as per day
  - - - online
      - secure
      - on-demand
  - - - As technology, market, and environmental complexities
      - their interactions have rapidly
        increased
  - - - proved especially effective
  - - - a small team of people
      - highly flexible
      - adaptive
    - - These strengths continue operating in single, several, many, and networks of teams
      - develop, release, operate and sustain the work and work products of thousands of people.
      - collaborate & interoperate
        
        through sophisticated development architectures
        
        and target release environments
- - - - could
        
        before Sprint time-box is over
      - Only PO has the authority
        
        although
        
        he/she may do so under influence from
        
        Stakeholders
        
        Dev Team
        
        Scrum Master
      - if
        
        Sprint Goal become obsolete
        
        because of
        
        the company changes direction
        
        market or technology conditions change
        
        in general
        
        Sprint is no longer makes sense given the circumstances
      - rarely make sense
        
        due to the short duration of Sprint
      - When Cancelled
        
        completed "Done" PBI
        
        reviewed
        
        if part of the work is potentially releasable
        
        PO accepts it
        
        typically
        
        all incomplete PBI
        
        re-estimated
        
        put back on PB
        
        the work done
        
        depreciates quickly
        
        must be frequently re-estimated
      - consume
        
        resources
        
        since
        
        everyone regroups in another Sprint Planning to start another Sprint
      - often traumatic
        
        to Scrum Team
        
        very uncommon
    - - a time-box of one month or less
        
        during which a "Done", usable, potentially releasable product Increment
        
        is created
    - - consistent durations
      - throughout
        
        a development effort
    - - Start immedidately
      - after the conclusion of the previous Sprint
    - - Sprint Planning
      - Daily Scrums
      - Development work
      - Sprint Review
      - Sprint Retrospective
    - - No changes
        
        are made
        
        would endanger the Sprint Goal
      - Quality goals
        
        do not decrease
      - Scope
        
        may be
        
        clarified
        
        re-negotiated
        
        between PO & Dev Team
        
        as more is learned
    - - may be considered
        
        a project
        
        no more than a one-month horizon
      - used to accomplish st
      - has
        
        Goal
        
        of what is to be built
        
        a design and flexible plan
        
        will guide building it
        
        the work
        
        the resultant product increment
    - - a Sprint's horizon
        
        too long
        
        definition of what being built may change
        
        complexity may rise
        
        risk may increase
      - Sprints
        
        enable predictability
        
        by ensuring inspection & adaption of progress
        
        toward a Sprint Goal
        
        at least every calendar month
      - Sprint limit risk
        
        to one calendar month of cost
  - - - an objective
        
        set for the Sprint
        
        can be met through the implementation of PB
      - provide
        
        Guidance
        
        to Dev Team
        
        on why it is building the Increment
      - created
        
        during
        
        Sprint Planning meeting
      - give
        
        Dev Team
        
        some flexibility
        
        regarding the functionality implemented
        
        within the Sprint
      - selected PBIs deliver one coherent function
        
        can be Sprint Goal
      - can be any other coherence
        
        cause Dev Team
        
        work together
        
        rather than on separate initiatives
      - keep in mind
        
        as Dev Team work
      - to satisfy
        
        implement
        
        functionality
        
        technology
      - negotiate the scope of Sprint Backlog
        
        within Sprint
        
        if the work turn out to be different than the Dev Team expected
        
        Dev Team collaborate with PO
    - - in a Sprint
      - is planned
        
        by
        
        collaborative work of the entire Scrum Team
    - - MAX = 8 hours/one-month Sprint
        
        Shorter Sprint --> usually shorter
      - Scrum Master
        
        ensure
        
        the event
        
        take place
        
        attendants
        
        understand its purpose
        
        teach
        
        Scrum Team
        
        keep it within the time-box
    - - What can be delivered
        
        in the Increment
        
        resulting from the upcoming Sprint
        
        Topic 1: What can be done this Sprint?
        
        Dev Team work to forecast
        
        functionality
        
        will be developed
        
        during the Sprint
        
        PO discuss
        
        objective
        
        Sprint should achieve
        
        PBIs
        
        if completed in Sprint
        
        would achieve the Sprint Goal
        
        entire Scrum Team
        
        collaborate on understanding
        
        the work of sprint
        
        Input to the meeting
        
        Product Backlog
        
        the latest product Increment
        
        Projected Capacity of Dev Team
        
        during the Sprint
        
        Past performance of Dev team
        
        number of items selected
        
        fr PB for the Sprint
        
        solely up to the Dev Team
        
        Only Dev Team
        
        can assess
        
        1 more item...
        
        craft
        
        a Sprint Goal
        
        during Sprint Planning
        
        by Scrum Team
      - How will the work needed
        
        to deliver
        
        the Increment be achieved
        
        Topic 2: How will the chosen work get done?
        
        Inputs
        
        Sprint Goal
        
        selected PBIs
        
        decide how it will build this functionality
        
        by Dev Team
        
        into a "Done" product Increment
        
        during Sprint
        
        Sprint Backlog
        
        PBIs selected
        
        for this Sprint
        
        Plan for delivering them
        
        usually start
        
        Dev Team
        
        by
        
        Design the system
        
        the work needed
        
        to convert the PB into working product Increment
        
        work
        
        may be of varying of
        
        estimated effort
        
        size
        
        however, enough work
        
        is planned
        
        during Sprint Planning
        
        for Dev Team
        
        to forecast
        
        1 more item...
        
        planned for the first days of the Sprint
        
        by the Dev Team
        
        is decomposed
        
        by the end of this meeting
        
        often to units of one day or less
        
        undertaked
        
        by
        
        self-organizing of Dev Team
        
        in the Sprint Backlog
        
        both
        
        during Sprint Planning
        
        as needed throughout the Sprint
        
        PO
        
        can help to
        
        make trade-offs
        
        clarify the selected PBIs
        
        renegotiate
        
        selected PBIs
        
        by Dev Team
        
        if
        
        Dev Team determine
        
        1 more item...
        
        Dev Team
        
        also invite other people
        
        to provide
        
        technical/domain advice
        
        end of Sprint Planning
        
        Dev Team should be able to explain to PO & SM
        
        how it intends to work
        
        as a self-organizing team
        
        to accomplish the Sprint Goal
        
        to create anticipated Increment
  - - - 15 minutes
    - - Dev Team
    - - every day of the Sprint
    - - for the next 24 hours
    - - team collaboration
      - performance
      - by
        
        inspecting the work
        
        since the last Daily Scrum
        
        forecasting
        
        upcoming Sprint work
      - probability
        
        Dev Team will meet Sprint Goal
        
        every day
        
        Dev team understand
        
        how it intends to work together
        
        as self-organizing team
        
        to accomplish
        
        Sprint Goal
        
        create the anticipated Increment
        
        by the end of the Sprint
    - - to inspect progress
        
        toward the Sprint Goal
      - to inspect
        
        how progress is trending
        
        toward completing the work
        
        in the Sprint Backlog
    - - det by Dev Team
      - can be conducted
        
        in different ways
        
        if it focuses on progress toward Sprint Goal
        
        some Dev Team will use
        
        questions
        
        more discussion based
        
        ex. 3 questions
        
        What did I do yesterday
        
        that helped the Development Team meet the Sprint Goal?
        
        What will I do today
        
        to help the Development Team meet the Sprint Goal?
        
        Do I see any impediment
        
        that prevents me or the Development Team from meeting the
        Sprint Goal?
    - - immediately
      - Development Team / team members
      - for
        
        detailed discussions
        
        to adapt
        
        replan
        
        the rest of Sprint's work
    - - ensure Dev Team has the meeting
      - teach
        
        keep the Daily Scrum
        
        within 15-minute time-box
    - - by Development Team
      - for conducting
    - - for Development Team
      - if others are present
        
        SM ensure they don't disrupt the meeting
    - - improve
        
        communications
      - eliminate
        
        other meetings
      - identify
        
        impediments to development
        
        for
        
        removal
        
        highlight
        
        promote
        
        quick decision-making
      - improve
        
        Dev Team's level of knowledge
  - - - at the end of the Sprint
      - to
        
        adapt
        
        Product Backlog if needed
        
        inspect
        
        the Increment
    - - int the Sprint
      - during Sprint Review
      - Scrum Team & Stakeholders
    - - to optimize value
      - based on
        
        what was done
        
        any changes to PB
        
        during the Sprint
      - by attendees
    - - not a status meeting
      - presentation of the Increment
        
        intended to
        
        foster collaboration
        
        elicit feedback
    - - shorter Sprints --> usually shorter
    - - ensure
        
        event take place
        
        attendees understand its purpose
      - tech
        
        everyone involve
        
        keep it within the time-box
    - - Attendees
        
        Scrum Team
        
        Key stakeholders
        
        invited by PO
      - PO explain what PBI have been
        
        "Done"
        
        NOT "Done"
      - Dev Team discuss
        
        during the Sprint
        
        what problems
        
        it ran into
        
        how resolved
        
        what went well
      - Dev Team
        
        demonstrate
        
        "Done" work
        
        Answer questions
        
        about the Increment
      - PO discuss PB
        
        as it stands
        
        projects likely
        
        delivery dates
        
        based on progress
        
        target
        
        if needed
      - Entire group collaborate
        
        on what to do next
        
        to provide
        
        valuable input
        
        to subsequent Sprint Planning
      - Review of how the marketplace / potential use of the product
        
        might have changed what is the most valuable thing to do next
      - Review
        
        timeline
        
        bugdet
        
        potential capabilities
        
        marketplace
        
        for the next anticipated releases
        
        of functionality/capability of the product
    - - revised PB
        
        define probable PBIs
        
        for the next Sprint
        
        may also be adjusted overall
        
        to meet new opportunities
  - - - for Scrum Team
      - to
        
        inspect itself
        
        create a plan
        
        for improvements
        
        to be enacted
        
        during next Sprint
      - focus on
        
        inspection
        
        adaptation
    - - after
        
        Sprint Review
      - prior to
        
        next Sprint Planning
    - - shorter Sprints --> usually shorter
    - - ensure
        
        the event takes place
        
        attendants
        
        understand its purpose
        
        is
        
        positive
        
        productive
      - teach
        
        all to keep it within time-box
      - participate
        
        as a peer team member
        
        in the meeting
        
        from accountability over Scrum process
      - encourage
        
        Scrum Team
        
        to improve
        
        within Scrum process framework
        
        its development process
        
        practices
        
        to make it more
        
        effective
        
        enjoyable
        
        for next Sprint
    - - Inspect how the last Sprint went with regards to
        
        people
        
        relationships
        
        process
        
        tools
      - Identify & order
        
        major items
        
        went well
        
        potential improvements
      - Create a plan for implementing improvements
        
        to the way the Scrum Team does its work
    - - Scrum Team
      - by
        
        improve
        
        work processes
        
        adapt
        
        definition of "Done"
      - if
        
        appropriate
        
        not in conflict with
        
        product
        
        organizational standards
    - - identified improvements
        
        Scrum Team have
        
        will implement in the next Sprint
        
        is adaption to the inspection of Scrum Team itself
        
        may be implemented at any time
  - - - regularity
    - - the need for meetings
        
        not defined in Scrum
    - - has a max duration
      - Sprint
        
        fixed duration
        
        cannot be shortened\lengthened
        
        once a Sprint begins
      - remaining events
        
        may end
        
        whenever
        
        the purpose of the event is achieved
        
        ensure
        
        an appropriate amount of time
        
        is spent without allowing waste in the process
  - - - all other events
  - - - inspect & adapt
        
        something
    - - enable
        
        critical transparency
        
        inspection
    - - results in
        
        reduced transparency
        
        a lost opportunity to
        
        inspect
        
        adapt
- - - - choose
        
        How best to accomplish their work
        
        rather than being directed by others outside the team
    - - have all competencies needed
        
        to accomplish the work
        
        without depending on others
        
        not part of the team
  - - - flexibility
      - creativity
      - productivity
  - - - all the earlier stated uses
      - any complex work
  - - - Incremental deliveries of "Done" product
        
        ensure a potentially useful version of working product
        
        is always available
    - - feedback
- - - - small enough
        
        to remain nimble
      - large enough
        
        to complete significant work
        
        within a Sprint
    - - decrease
        
        interaction
        
        results
      - in smaller productivity gains
      - may encounter
        
        skill constraints
        
        during Sprint
        
        causing Dev Team
        
        unable to
        
        deliver a potentially releasable Increment
    - - require
        
        too much coordination
      - generate
        
        too much complexity
        
        for an empirical process
        
        to be useful
    - - Unless
        
        they are also executing the work of the Sprint Backlog
  - - - do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint
  - - - members of Development Team
  - - - the organization
    - - organize & manage
        
        their own work
    - - optomize
  - - - No one (even Scrum Master)
        
        tell Development Team
        
        How to turn PB into Increments of Potentially releasable functionality
    - - All skills ass a team necessary
        
        to create a product Increment
    - - regardless of
        
        the work being performed by the person
    - - regardless of domains that need to be addressed like
        
        testing
        
        architecture
        
        operations
        
        business analysis
    - - but, accountability belongs to the Development Team as a whole
- - - - Ensure Goals, Scope, Product Domain are understood
        
        by everyone on Scrum Team
        
        as well as posible
      - Find techniques
        
        for effective Product Backlog mgmt
      - Help Scrum Team
        
        understand the need for clear & concise PBIs
      - Understand
        
        Product Planning
        
        in an empirical environment
      - Ensure PO know
        
        How to arrange PB
        
        To maximize value
      - Understand & practice
        
        Agility
      - Facilitate
        
        Scrum events
        
        as requested or needed
  - - - Coach
        
        Development Team
        
        Self-organization
        
        Cross-functionality
      - Help Development Team
        
        Create high-value products
      - Remove
        
        Impediments
        
        to the Development Team's progress
      - Facilitate
        
        Scrum events
        
        as required or needed
      - Coach
        
        Development Team
        
        in organizational environments
        
        Scrum is not yet
        
        fully adopted
        
        understood
  - - - Lead & coach
        
        organization
        
        in its Scrum adoption
      - Plan
        
        Scrum implementations
        
        within organization
      - Help
        
        Employees & Stakeholders
        
        Understand & enact
        
        Scrum
        
        empirical product development
      - Cause change
        
        increase
        
        productivity of Scrum Team
      - Work with other Scrum Masters
        
        to increase
        
        effectiviness of application of Scrum
        
        in organization
  - - - as defined in Scrum Guide
      - by
        
        helping everyone understand
        
        Scrum theory
        
        pratices
        
        rules
        
        values
  - - - understand
        
        interactions with Scrum Team
        
        not helpful
        
        helpful
      - change these interactions
        
        to maximize the value
        
        created by Scrum Team
- - - - known to be needed in the product
    - - for any changes to be made
        
        to the product
    - - by PO
      - include
        
        content
        
        availability
        
        ordering
    - - earliest development of it layout
        
        the initially known
        
        best-understood requirements
    - - as the product & environment in which it will be used evolves
    - - constantly changes to identify what the product needs to be
        
        appropriate
        
        competitive
        
        useful
      - if a product exists
        
        PB also exists
    - - features
      - funtions
      - requirements
      - enhancements
      - fixes
      - that constitute the changes
        
        to be made to the product
        
        in future releases
    - - attributes
        
        description
        
        order
        
        estimate
        
        value
      - often include
        
        test descriptions
        
        prove its completeness
        
        when "Done"
    - - larger & more exhaustive list
      - as
        
        product is used & gain value
        
        marketplace provides feedback
    - - requirement never stop changing
      - changes may cause changes in
        
        business requirements
        
        market conditions
        
        technology
    - - Multi Scrum Team often work together on the same product
      - BP is used to describe the upcoming work on the product
      - A PB attribute that groups items may then be employed
    - - act of adding ... to PBIs
        
        details
        
        estimates
        
        order
      - ongoing process
        
        PO & Dev Team collaborate
        
        on details of PBIs
      - PBIs
        
        reviewed
        
        revised
        
        however
        
        can be updated at any time
        
        by PO
        
        at the PO's direction
      - Scrum Team decides
        
        How & When the refinement done
      - consume
        
        < 10% of capacity of Dev Team
        
        usually
      - Order
        
        higher
        
        usually
        
        clearer
        
        more detailed
        
        estimate
        
        more precise
        
        lower
        
        less detail
      - PBIs will occupy the Dev Team for upcoming Sprint
        
        refined
        
        any one item can be reasonably be "Done"
        
        within the Sprint time-box
        
        "Ready" for selection in a Sprint Planning
        
        usually acquire this degree of transparency
        
        through refining activities
      - estimates
        
        by Development Team
        
        PO may influence the Dev Team
        
        by help it understand & select trade-offs
        
        final estimate
        
        made by people who will perform the work
    - - total work remaining to reach a goal
        
        can be summed
        
        at any point of time
        
        PO
        
        compare
        
        previous Sprint Reviews
        
        to assess progress toward completing projected work
        
        by the desired time for the goal
        
        transparent
        
        to all stakeholders
        
        track
        
        every Sprint Review
        
        at least
      - forecast progress
        
        various projective practices
        
        burn-downs
        
        burn-ups
        
        cumulative flows
        
        proven useful
        
        do not replace the importance of empiricism
        
        complex environments
        
        what will happen is unknown
        
        only what already happened
        
        may be used
        
        for forward-looking decision-making
  - - - set of PBIs
        
        selected for the Sprint
      - a plan for
        
        delivering the product Increment
        
        realizing the Sprint Goal
      - a forecast
        
        by Dev Team
        
        about what functionality will be in the next Increment
        
        the work needed to deliver that functionality into a "Done" Increment
      - a plan
        
        detail
        
        enough
        
        changes in progress can be understood
        
        in Daily Scrum
        
        modified
        
        by Development Team
        
        throughout Sprint
        
        emerge
        
        during sprint
        
        as
        
        Dev Team works through the plan & learns more
        
        about the work needed to achieve the Sprint Goal
    - - Dev Team identifies as neccessary
        
        to meet Sprint Goal
        
        be made visible
      - include
        
        high priority process improvement
        
        at least one
        
        identified in the previous Retrospective meeting
        
        to ensure continuous improvement
    - - Add
        
        New work
        
        if required
      - update
        
        estimated remaining work
        
        as
        
        performed
        
        completed
      - remove
        
        elements of plan deemed unnecessary
      - Only Dev Team can
        
        during Sprint
    - - highly visible
      - Dev Team plan to accomplish
        
        during Sprint
      - belongs solely to Dev Team
    - - total work remaining
        
        in Sprint Backlog
        
        can be summed
        
        at any point in time in a Sprint
        
        tracked
        
        by Dev Team
        
        every Daily Scrum
        
        at least
        
        to project
        
        the likelihood of achieving the Sprint Goal
        
        can manage Sprint's progress
  - - - sum of all PBIs
        
        completed
        
        during a Sprint
      - value of increments of all previous Sprints
    - - at the end of a Sprint
      - must
        
        be in usable condition
        
        meet Scrum Team's Definition of "Done"
    - - support empiricism
        
        at the end of the Sprint
    - - regardless of whether PO decides to release it
  - - - transparency
      - oppotunities
      - for
        
        inspection
        
        adaptation
  - - - to maximize transparency of key information
      - so everybody has same understanding
- - - - by everyone
        
        MUST
        
        to ensure transparency
      - shared understanding of what it means for work to be complete
    - - per Scrum Team
    - - when work is complete
        
        on product Increment
    - - Dev Team
      - know how many PBIs
        
        can select during a Sprint Planning
      - purpose of each Sprint
        
        deliver Increments of potentially releasable functionality
        
        adhere to the Scrum Team's current definition of "Done"
    - - if is part of ... of development organization
        
        conventtions
        
        standards
        
        guidelines
        
        must follow
        
        all Scrum Team
        
        as minimum
        
        because of
        
        Increment
        
        useable
        
        PO may choose to release
        
        immediately
        
        delivered
        
        by Dev Team
        
        every Sprint
      - if not
        
        Dev Team must define
        
        appropriate for the product
        
        multi Scrum Teams
        
        all the Scrum Teams must mutually define the definition of “Done.”
        
        working on the system/product release
    - - is additive to all prior Increments
      - thoroughly tested
        
        ensure all Increments work together
    - - as Scrum Team mature
      - expand to include
        
        more stringent criteria
        
        for higher quality
      - new definitions
        
        may uncover work
        
        to be done
        
        in previously "Done" increments
        
        as used
        
        any one product or system should have a definition of "Done"
        
        that is a standard for any work done on it
  - - - decisions have a sound basis
    - - decisions can be flawed
      - value may diminish
      - risk may increase
  - - - perceived state of the artifacts
  - - - SM
      - PO
      - Dev Team
      - other involved parties
    - - for coping with incomplete transparency
      - SM help everyone
        
        apply the most appropriate pratices
        
        in the absence of complete transparency
    - - by inspecting the
        
        artifacts
        
        sensing patterns
        
        listening closely to what is being said
        
        detect differences
        
        between expected & real results
  - - - with
        
        with the Scrum Team
        
        organization
      - to increase
        
        transparency of the artifacts
      - usually involve
        
        learning
        
        convincing
        
        change
    - - but is a path
- - - - Scrum Team members have courage to
      - do the right thing
      - work on tough problems
    - - everyone focuses on
      - the work of the Sprint
      - the goals of the Scrum Team
    - - Scrum Team & its stakeholders agree to be open about
      - all the work
      - challenges with performing the work
    - - Scrum Team members respect
      - each other
      - to be capable, independent people
    - - people personally commit to
      - achieving the goals of the Scrum team
  - - - as working with
        
        roles
        
        events
        
        artifacts
  - - - people becoming more proficient in
      - living these 5 values
- - - - KNOWLEDGE come from EXPERIENCE
      - MAKING DECISIONS based on WHAT IS KNOWN
  - - - ITERATIVE
      - INCREMENTAL
    - - optimize
        
        Predictability
      - control
        
        Risk
  - - - Significant aspects of the process
        
        MUST BE VISIBLE
        
        To those responsible for the OUTCOME
        
        be defined by
        
        a COMMON STANDARD
        
        common language
        
        referring to the process
        
        all participants
        
        Definition of "DONE"
        
        those performing the work
        
        those inspecting the resulting increment
        
        so
        
        observers share a
        common understanding of what is being seen.
    - - frequently inspect
        
        artifacts
        
        progress
        
        toward
        
        a Sprint Goal
      - to detect
        
        undesirable variances
      - Who
        
        Scrum users
      - Should NOT
        
        SO Frequent
        
        gets in the way of the work
      - most BENEFICIAL
        
        diligently performed
        
        by skilled inspectors
        
        at the point of work
    - - an inspector determines
        
        An adjustment must be made as soon as possible
        
        to minimize further deviation.
        
        one or more aspects of a process
        
        deviate outside acceptable limits
        
        resulting product will be unacceptable
        
        the process or the material being processed must be adjusted.
      - 4 events
        
        Sprint Planning
        
        Daily Scrum
        
        Sprint Review
        
        Sprint Retrospective
        
        for inspection and adaptation
- - - - the value of product resulting from
        
        work of the Development Team
    - - may vary widely across
        
        organization
        
        Scrum Teams
        
        individuals
  - - - managing Product Backlog
        
        express
        
        Product Backlog items
        
        clearly
        
        Order
        
        Product Backlog Items
        
        to best achieve goals & missions
        
        Optimize
        
        The value of the work
        
        the Development Team performs
        
        Ensure
        
        Visiable
        
        Transparent
        
        Clear
        
        Show what the Scrum Team will work on next
        
        Ensure
        
        Development Team
        
        understand items
        
        to the level needed
    - - may do the work
      - have Development Team do it
        
        remain accountable
    - - not a committee
      - may present the desire of a committee
        
        in PB
      - but those wanting to change a PBI's priority
        
        must address the Product Owner
  - - - visible in
        
        content
        
        ordering of PBI
    - - to work from a different set of requirements
- - - - be instrumental at start
        
        Jeff Sutherland
        
        Jeff McKenna
        
        John Scumniotales
        
        Ken Schwaber
        
        Mike Smith
        
        Chris Martin
  - - - until 1995
      - co-presented Scrum
        
        at OOPSLA Conference
        
        essential documented the learning
        
        gained over previous few years
        
        made public the first formal definition of Scrum
    - - described elsewhere
      - first places tried & refined
        
        Individuals, Inc.
        
        Newspage
        
        Fidelity Investments
        
        IDX
        
        GE Medical
    - - document Scrum as
        
        developed
        
        evolved
        
        sustained
        
        for +20 years
        
        by
        
        Jeff Sutherland
        
        Ken Schwaber
      - Other sources
        
        provide
        
        patterns
        
        processes
        
        insights
        
        complement Scrum framework
        
        may increase
        
        productivity
        
        value
        
        creativity
        
        satisfaction
        
        with results
- - - - in the Scrum Guide
    - - immutable
    - - possible
      - result = not Scrum
    - - its entirety
    - - as a container for other
        
        methodologies
        
        practices
        
        techniques