1. Sprints
   1. PO's role in Scrum Meetings
      1. ttend and actively participate in the Sprint Planning Meeting
      2. PO comes to the Sprint Planning meeting with a Product Backlog that is well prepared
         1. with items at the upper part of the Product Backlog that are clearly thought through
         2. provide sufficient detail for the team to be able to make a commitment for the Sprint
      3. Teach that the Daily Scrum Meeting is the development team’s meeting
         1. Teach that the Product Owner may attend the Daily Scrum Meeting only at the invitation of the team, and may not interfere
         2. not intended as an update for the Product Owner
   2. Product Owner and Development Team collaborate during the Sprint
      1. PO should be fully available to answer questions and clarify details that the development team requires in order to deliver their commitment
      2. PO should not disrupt or interfere with the development team
      3. the Sprint Commitment does not change, and that the Product Owner should not attempt to introduce new or changed items during the Sprint
      4. in the event of a significant change in circumstances, the Product Owner may choose to terminate the Sprint and ask the Development Team to begin a new one
      5. if the Product Owner identifies new requirements during the Sprint, they should be placed on the Product Backlog to be worked on in a future Sprint
      6. Product Owner and development team should together decide the Sprint length
      7. once the Sprint begins, its duration is never extended
      8. Sprint commitment does not equal a guarantee
   3. Understand what team commitment means
   4. Understand why Sprints are timeboxed and protected
   5. Understand the concept of sustainable pace
2. Scrum Basics
   1. Scrum Framework
      1. Roles: Scrum Master, PO, Team
      2. Backlog
         1. List of product features
         2. Detailed appropriately
         3. Emergent
         4. Sized
         5. Prioritized
      3. Sprint
         1. Four meetings
         2. Two inspect and adapt cycles
         3. Outcome
            1. Potentially Shippable Product Increment
         4. Timeboxed
         5. Protected from any changes
         6. Max duration is a calendar month
      4. Mandatory, cannot be compromised
      5. Definition of Done
         1. Criteria the PSPI must fulfill at the end of a Sprint
            1. Thoroughly tested
            2. Free of defects
            3. Refactored
            4. Adequately documented
            5. "shippable"
      6. Iterative-incremental software development principles
         1. Implemented in the form of vertical slices
         2. each "slice" provides value
         3. Each increment extends the previous increment
   2. Empirical process control
      1. Transparency
      2. Inspect for cause
      3. Adapt to identify improvement measures
      4. Scrum does not prescribe HOW the team works
      5. Lack of sophisticated reporting as a consequence
   3. Scrum Culture
      1. Collaboration
      2. Enjoy work
      3. Create software that benefits users and customers
3. Values
   1. Agile Manifesto
   2. Scrum Values
      1. Commitment
      2. Focus
      3. Openness
      4. Respect
      5. Courage
4. Product Owner Role
   1. Establish High Level Vision and Goals
      1. What the project will create
      2. For whom
      3. why
   2. Establish the budget for the development work
   3. Creating the backlog
      1. Prioritized
         1. Value
         2. Size
         3. Risk
         4. Other relevant considerations
   4. Part of team
      1. Provides team context/detail team requires to deliver features/functionality
         1. necessary for team to make commitment
         2. motivates team
      2. Provides whatever input/assistance the team requests
      3. Engaged with the team throughout the Sorint
         1. Provides input/assistance as required
         2. but does not disrupt or interfere
   5. inspects features/functionality each Sprint Review
      1. Identifies ways to improve business value
      2. looks for insights about opportunities, constraints, risks...
         1. Evolves Product backlog from Sprint to Sprint
   6. Decides when to release to the market/customer
      1. Maintains clear release criteria
         1. Release Date
         2. and/or Release Scope
         3. Communicates via Release Burndown
            1. Shared with stakeholders/team
   7. Not permitted to disrupt team or change commitment
      1. Except in event of major change in circumstances
         1. May terminate Sprint and plan new one
   8. Optimizes ROI of the product
   9. Manages stakeholders
   10. Individual, Not a committee
   11. Role typically played by customer or customer representative
       1. such as Product Manager
5. Scrum Master Role
   1. Enable high performing teams
   2. Change agent
      1. Remove Waste
      2. Product business value early and often
   3. Teaches Scrum
      1. To the team
      2. PO
      3. Others in the organization
   4. Chief Impediment Remover
   5. Enables team to deliver high-quality PSPI each Sprint
      1. Helps the team remove obstacles and impediments
      2. Protects the team from disruption
      3. Coaches team on their practices
   6. Facilitates interactions as needed
      1. Team
      2. PO
6. Team
   1. 7 +/- 2
   2. 100% dedicated to the Sprint
   3. Should sit together
   4. Self-organized, empowered to decide how much work to pull into a Sprint
   5. Collectively responsible for achieving the Sprint Goal and meeting the commitment
   6. Self-disciplined
      1. Responsible for working diligently to produce high-quality, potentially shippable functionality each Sprint
      2. Works without sacrificing a sustainable pace of work
      3. Works without sacrificing long-term quality of work delivered
   7. Scales by having multiple teams (organized of teams of teams) rather than large teams
   8. Teams include all the skills necessary to produce a high-quality increment of potentially shippable product
   9. Not constrained in work they may do by their prior role designation (coder, tester, etc)
7. No Project Manager and No Agile Product Manager
   1. Scrum addresses the prior responsibilities of the Project MAnager through the Roles of Product Owner, Scrum Master and Team
   2. A delegation of responsibilities (for example, from PO to PM or Agile Product Manager) will introduce risk, dysfunction, and waste
8. Vision
   1. Importance of Vision
      1. Shared goal: product vision describes the common goal; it aligns the Scrum team members and stakeholders pulling everyone in the same direction.
      2. vision should state the customers and users of the software, the needs addressed, and the most important product attributes. It may also compare the product to existing ones and state the revenue model.
   2. Desirable qualities of Vision
      1. Shared
      2. Broad and engaging
      3. Concise: captured on 1 or 2 flipcharts
   3. How to shape a Vision
      1. Techniques
         1. Vision box, elevator statement, press release, magazine review, one page data sheet, personas and scenarios, Kano Model
   4. Just enough prep work
      1. The upfront work in Scrum to create a product vision should be minimized; just enough work to create a vision that gels the team and creates forward momentum
      2. Potential dangers
         1. Rushing into the project without an overall goal
         2. procrastinating the project and being trapped in analysis- paralysis
      3. different products and domains require a different amount of prep work
      4. Avoid fallacy of trying to predict the future
   5. Relationship between Vision and Product Roadmap
      1. As the product matures and incremental updates are released, the visioning effort usually declines. New product versions still need to have goals to align the Scrum team and stakeholders. Visioning now forms part of creating and updating the product roadmap.
      2. A product roadmap is a planning artifact that shows how the product is likely to evolve across releases and product versions, facilitating a dialogue between the Scrum team and the stakeholders.
9. Estimating (Sizing)
   1. Different estimation levels
      1. Product Backlog
         1. Story Points (or hours)
         2. ideal days
      2. Tasks
         1. hours
      3. Purpose of estimating
         1. Product Backlog
            1. The product backlog estimates enable the product owner to prioritize work and the Scrum team to determine the effort remaining to deliver the release thereby tracking the progress and creating a release plan
         2. Tasks
            1. task estimates help the team to pull the right number of product backlog items into the sprint allowing the team to make a realistic commitment.
   2. Accuracy vs precision
      1. an accurate estimate may be useful even if its precision is less than the product owner would like
      2. an inaccurate (but precise) estimate is of no use
      3. estimates in Scrum are team estimates and should not include any assumptions abut who is going to implement a product backlog items or sign up for a task
   3. Size vs duration
      1. the team should estimate the size of the effort and then velocity should be used to empirically determine the duration. Size and duration can independently
   4. Impact of pressuring teams
      1. team members will provide low estimates when forced and won’t finish the work within that time
      2. excessive time pressure leads to cutting quality (which comes back to hurt the project later), low morale, and loss of creativity
   5. Estimating vs committing
      1. estimate is a prediction of the future and always includes some amount of uncertainty
      2. a commitment is based on an estimate, which must be created first
      3. implications of equating estimating with committing
10. Product Backlog
    1. What it is/is not
       1. The product backlog is a list of requirements and other deliverables necessary to turn the vision into a successful product. The product backlog must must be Detailed appropriately, Estimated, Emergent, and Prioritized (DEEP)
       2. not a substitute for a requirements specification
       3. evolves and changes constantly; many of its items are coarse-grained and sketchy to start with; they are then progressively decomposed and refined
       4. emphasis shifts from documentation to conversation, from specifying requirements to having an ongoing dialogue
       5. product backlog can have different forms and shapes
          1. a collection of paper cards or be held electronically as a spreadsheet or in a specialized tool
          2. can be flat or structured employing several columns and grouping items into themes, for instance
          3. can be augmented as appropriate with other artifacts
             1. Spreadsheet showing business rules
             2. Visio diagram showing a workflow
             3. user interface prototype or mockup
             4. only used when necessary and kept as light as possible
    2. Product Backlog Refining (Grooming)
       1. Steps to groom the product backlog such as discovering new requirements, and updating or removing existing ones; prioritizing the backlog; preparing high-priority items for the next sprint planning meeting; estimating items.
       2. approaches to stocking the product backlog and determining the release scope such as deriving the contents from the product vision
       3. just-enough requirements are identified and described just in time according to their priority throughout the entire project
       4. grooming the product backlog is a collaborative effort shared by all Scrum team members
       5. the product owner leads the efforts
       6. members can spend up to 10% of their time on grooming
       7. often involves customers and users and other stakeholders including marketing and sales
       8. high-priority items to be worked on in the next sprint must be small enough to be fully transformed into a product increment. They should also be clear and testable.
       9. Share at least one technique suitable to capture product backlog items, for instance, user stories
       10. Share how non-functional requirements can be dealt with in the product backlog
11. Prioritizing
    1. Importance/benefits of prioritizing the Product Backlog
       1. it is important to prioritize the backlog because the team is expected to work in approximately priority order
       2. because it is impossible to perfectly predict a schedule and the contents of a release, there is always the chance that a product will need to be shipped sooner than planned or with fewer features
       3. a prioritized product backlog enables the team to maximize the delivery of value to the customer over a given period of time
       4. prioritizing a product backlog involves both determining what product backlog items will be planned to be in the upcoming release and the general sequence in which they will be built
          1. The sequence should be more approximate the further out in time the features are
    2. Implications of saying everything is mandatory
       1. it is important to prioritize work even on a fixed-scope project for which all features are mandatory
       2. since not all work can be done simultaneously, even a fixed-scope project will still benefit from prioritizing work at the start of each sprint
          1. even though all features may be considered mandatory, some features should be developed sooner so that they can be shown earlier to users for feedback
       3. even though a team plans and commits to deliver all features on a fixed-scope project, that does not always happen: Project schedules are sometimes shortened, teams make mistakes, and so on.
    3. Who has input to prioritization decisions
       1. it is important for the product owner to incorporate the opinions of many diverse stakeholders
       2. opinions about priorities should be sought from users, customers and other business-side stakeholders, depending on the application
       3. important to seek opinions about priorities from the developers
          1. Such developers are often in the best position to comment on risk and changes over time in the relative cost of product backlog items
    4. Prioritization based on multiple factors
       1. desirability of the few features or capability
       2. amount of learning that will be created by working on the feature
       3. extent to which risk is reduced by developing the feature
       4. any changes in the relative cost of the feature over time
    5. Formal approaches
       1. Teach at three options
          1. Non-financial
             1. Moscow
             2. Relative weighting
             3. theme screening
             4. Imact estimation
             5. theme scoring
          2. Financial
             1. NPV
             2. ROI
             3. Discounted payback period
             4. economic value added
       2. Many techniques, there are limitations of formal approaches and specific approaches applied
    6. Giving latitude to teams adjusting sequence of work
       1. team should generally be given some latitude in sequencing work into sprints
       2. many reasons for working slightly out of order
       3. An effective product owner is aware of these situations and works with the team to determine their appropriate application
12. Release Management
    1. Understand the goals of Release Management
       1. Primary goal: is to bring the vision to life in the best possible way—to develop a product that benefits the customer/user and the organization creating it
       2. successful release management relies on an evolving and improving understanding of user or customer needs
       3. release management consists of
          1. estimating product backlog items
          2. tracking the progress using release burndown charts
          3. creating a release plan
             1. Release Plans are not a mandatory part of the Scrum Framework
    2. Planning is Adaptive, iterative and collaborative
       1. planning takes place at different levels in Scrum: Product, release, sprint, and day
       2. release planning is spread throughout a project, not just early on
       3. Plans in Scrum are dynamic and change as more information about the customer needs and the product being developed becomes available
       4. release planning activities are carried out by the Scrum team often with the help of stakeholders
       5. product owner ensures that the necessary release management activities
    3. Quality vs technical debt
       1. quality is defined in the definition of done. It is no longer a variable but fixed
       2. quality compromises lead to technical debt, the software becomes brittle and expensive to extend and maintain
       3. short release cycles and frequent software updates require high quality
    4. software should be released early and frequently
       1. product increments should be released to target customers early and frequently instead of delivering the finished product in one go
       2. early and frequent releases allow incorporating feedback from customers and users, creating a product that meets the needs of its use
    5. Velocity
       1. defined by the amount of effort earned by the team per sprint
       2. only items delivered according to the definition of done contribute to the velocity
       3. best observed / measured empirically
          1. usually requires running at least 2-3 sprints unless the team has worked together on the previous product version
       4. can help the team optimize its velocity
          1. by ensuring that high-priority product backlog items are clear, feasible and testable
          2. by jointly detailing high-priority items
          3. by answering questions in timely manner
    6. Release Burndown/ burnup
       1. simple report that creates transparency about the project progress relating time and the effort remaining in the product backlog
          1. allows the Scrum team and stakeholders to understand how the project is doing
       2. release burndown chart looks at the past sprints and projects their velocity into the future
          1. allows the Scrum team to make informed decision about managing functionality, time and cost
          2. updated at the end of each sprint when the remaining effort in the product backlog and the velocity are known
       3. no substitute for attending the sprint review meeting to fully understand the project progress and for engaging in dialogue with the Scrum team.
    7. Release Plan
       1. can help forecast the future
       2. release plan is a rough forecast, not a commitment and certainly no guarantee
       3. no substitute for a project plan; it contains less detail and is updated in each sprint
       4. A traditional project plan no longer exists in Scrum
       5. What is it
          1. a release plan is based on the amount of work remaining in the product backlog and the velocity
          2. It looks ahead into the future forecasting delivery date, cost and functionality by anticipating
             1. velocity of the remaining sprints
             2. dependencies to partners and suppliers
             3. any releases such as alpha and beta releases