Scrum Events

• All events are held at the same time and place to reduce complexity
• Each event is designed to enable transparency and is a formal opportunity to inspect and adapt Scrum artifacts
• Create regularity and minimize the need for meetings not defined in Scrum
• the heartbeat of Scrum, where ideas are turned into value
• The entire purpose of the Scrum events is to offer a clear cadence, rhythm and focus that prevent unnecessary meetings and task switching
• Sprint
  • fixed length events of 1 month or less: Once begins, its duration is fixed & cannot be shortened or lengthened
  • new Sprint starts immediately after the conclusion of the previous Sprint
  • all the work necessary to achieve the Product Goal happen within Sprints
  • enable predictability: by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month
  • Sprint’s horizon is too long:
    • the Sprint Goal may become invalid, complexity may rise, and risk may increase
  • So, shorter Sprints:
    • more learning cycles and limit risk of cost and effort to a smaller time frame
  • could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority
  • Characteristics
    • No changes are made that would endanger the Sprint Goal
    • Quality does not decrease
    • Scope may be clarified and renegotiated with the Product Owner as more is learned
    • The Product Backlog is refined as needed
  • Commit vs Forecast
    • Some understand commitment as all the PBIs taken by the Developers to be completed within a Sprint
    • definition of “commit” is: To bind or obligate, as by pledge or assurance; pledge: to commit oneself to a promise; to be committed to a course of action
    • many Scrum Teams use the word commit as if it were a “guarantee.” This is a residue of waterfall, where an estimate was a contract
    • team that feels they have to do anything to deliver their commitment. The usual victim is quality
    • Developers commit to the Sprint Goal and commit to do the best they can, the PBIs selected are a forecast of what they estimate they can complete within a sprint and what can help to fulfil the Sprint Goal
  • 5 Powerful things
    • Focus
      • What value is to be delivered is guided by the Sprint Goal, which does not change during the Sprint. Because… well, focus
      • product development chaotic, new ideas, new business needs up, new information
      • By having this single purpose every Sprint –create a releasable Increment– set aside distractions not related, take the new information and adapt plan without losing focus
    • Predictability
      • While may not be able to guarantee the specific scope of the Increment, a team that is using Scrum well will be predictable in delivering a “Done” Increment every Sprint
      • Sprints consistent cadence helps understand what they are capable of delivering in a period of time. better forecast delivery expectations
      • The Sprint helps us optimize predictability over time (estimate and forecast more accurate)
      • Scrum Team can change the length of a Sprint, but they don’t change it constantly. They do so settle into a new cadence
    • Control
      • the real driver of the length of a Sprint is how often the business needs to inspect the Increment and adapt the direction based on new information
      • This gives the business control without creating an unstable situation
      • the Sprint time-box gives the business more transparency to and control of cost and schedule
      • Control business risk: An organization can fund a number of Sprints and see the value they are getting every Sprint
      • helps make informed decisions about whether or not to keep investing money and on what
    • Freedom
      • focus of a Sprint Goal and a time-box: These boundaries create the freedom for
        • effective self-organization, collaboration, and experimentation
        • renegotiate the scope as far as the Sprint Goal is not endangered
      • Risk is minimized to the length of the sprint, allows to provide freedom to the Scrum Team
      • There are many ways risk shows up in product development. Teams have to learn by doing, inspecting and adapting along the way
      • failure is a part of learning. The question is how big of an impact that failure will have. A Sprint limits the impact of failure to the time-box of the Sprint
    • Opportunity
      • It’s about being open to and ready for the opportunities you discover throughout the journey
  • Teamwork, developers never work in isolation, collaboration include,> during the creation of the increment:
    • Helping peers to complete work in progress before bringing in new work from a backlog
    • Pair programming, such as taking it in turns to use the keyboard and helping and checking each other’s work
    • Peer review
    • Asking for help, and being keen to give it
    • Going to where the work is and helping, instead of waiting for work to be passed over to them
    • Making sure that all work does in fact meet the Definition of Done
    • Calling a Scrum in order to resolve problems which need the team’s immediate attention
    • Raising impediments to the Scrum Master so they can be handled in a timely manner
    • Updating a Scrum Task board and burndown chart so that the information is up-to-date and can be relied on
    • Skill and knowledge sharing

Myth: In Scrum, we spend too much time in meetings

• When Scrum is introduced, DTs tend to enthusiastically embrace it
  • Scrum promotes self-organization, autonomous, multidisciplinary teams and acknowledges individual qualities and contributions to a team effort
  • Who doesn’t want to be part of a Scrum Team?
• Quite often however, after the Scrum honeymoon, people start raising issues:
  • “Since Scrum, all I do is attend meetings. I didn’t become a developer to attend meetings all day.”
  • “With Scrum I hoped we would get a team culture, but instead it feels more like a meeting culture.”
  • “I thought Scrum meetings were time boxed, but our daily Scrum takes at least 30m and afterwards we still don’t have a solid plan as a team.”
• MY ANSWER:
  • Do you prefer to be micro managed and someone impose what you have to do? And measure your performance based on unfair criterias?
  • It Is not about how fast or far we run, is about which direction we take, value over features and quality over quantity
  • Meetings have potential value, if we do not get it, ask ourselves why? Take the blame
  • All people think the same… that may be good but not here… you are not so different from the rest
• These frustrations drive some Scrum Teams to abandon
• The Scrum Guide describes
  • five Scrum events (not ‘meetings’)
    • create regularity
    • minimize the need for meetings not defined in Scrum
  • Every event
    • has a clear purpose
    • plays an important role in the inspect-and-adapt cycle of Scrum
    • is time-boxed, which means they have a maximum duration
• two of the issues behind this myth
  • Factually, how time-consuming are the Scrum events?
  • Should we spend (this much) time on these events?
• The origins of this myth
• TIPS - What can you do to improve the effectiveness and make them more enjoyable?

Manager’s schedule AND Maker’s schedule

• Manager’s schedule: