Please enable JavaScript.

Coggle requires JavaScript to display documents.

SCRUM (TEAM ((Zespół Deweloperski (ang. Development Team) (SCRUM MASTER…

- - - - 3 pillars
        
        Inspection
        
        Inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.
        
        Inspection should not be so frequent that inspection gets in the way of the work.
        
        Adaptation
        
        If resulting product will be unacceptable, the process or the material being processed must be adjusted.
        
        4 formal evens for inspection:
        
        Codzienny Scrum (ang. Daily Scrum)
        
        Przegląd Sprintu (ang. Sprint Review)
        
        Planowanie Sprintu (ang. Sprint Planning)
        
        Retrospektywa Sprintu (ang. Sprint Retrospective)
        
        Transparency
        
        common standard
        
        common language
        
        common understanding
        
        Definition of Done - common for the one who is performing the work and the one who is accepting the work
        
        Significant aspects of the process must be visible to those responsible for the outcome.
  - - - openness
      - respect
      - focus
      - commitment
      - courage
- - - - Leading and coaching the organization in its Scrum adoption
      - Planning Scrum implementations within the organization
      - is a servant-leader for the Scrum Team
      - Helping employees and stakeholders understand and enact Scrum and empirical product development
      - helping everyone understand Scrum theory, practices, rules, and values.
      - Causing change that increases the productivity of the Scrum Team
      - is responsible for promoting and supporting Scrum as defined in the Scrum Guide
      - Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization
    - - They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality
      - Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment
      - Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person
      - Only members of the Development Team create the Increment.
      - Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis
      - Development Team consists of professionals who do the work of delivering a Increment of "Done"
      - Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole
      - Having more than nine (9) members requires too much coordination
      - SCRUM MASTER SERVICE
        
        Helping the Development Team to create high-value products
        
        Coaching the Development Team in self-organization and cross-functionality
        
        Removing impediments to the Development Team’s progress
        
        Facilitating Scrum events as requested or needed
        
        Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood
    - - Clearly expressing Product Backlog items
      - Ordering the items in the Product Backlog to best achieve goals and missions
      - responsible for managing the Product Backlog
      - Optimizing the value of the work the Development Team performs
      - is responsible for maximizing the value of the product resulting from work of the Development Team
      - Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
      - Ensuring the Development Team understands items in the Product Backlog to the level needed
      - SCRUM MASTER SERVICE
        
        Understanding product planning in an empirical environment
        
        Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value
        
        Helping the Scrum Team understand the need for clear and concise Product Backlog items
        
        Finding techniques for effective Product Backlog management
        
        Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible
        
        Understanding and practicing agility
        
        Facilitating Scrum events as requested or needed
- - - - Longer than one month can
        
        complexity may rise
        
        the definition of what is being built may change
        
        risk may increase
    - - Daily Scrums
      - development work
      - Sprint Planning
      - Sprint Review
      - Sprint Retrospective
    - - Quality goals do not decrease
      - Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned
      - No changes are made that would endanger the Sprint Goal
    - - Only the Product Owner has the authority to cancel the Sprint
        
        may do so under influence from the stakeholders, the Development Team, or the Scrum Master
      - A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances.
      - When a Sprint is cancelled, any completed and "Done" Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.