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?
    • 4 weeks sprint, 160 hours of work, 36 hours max. in events and PBR (22,5% of the time)
  • Should we spend (this much) time on these events?
    • Development Is complex, require collaboration, central to this are conversations, about:
      • what has been done
      • whether or not that actually worked
      • what should be done next
    • Scrum provides a minimal set of boundaries (5 events, 3 roles, 3 artifacts) to have focusses conversations on what is important, when, and with who
    • Spending time on the Scrum events is incredibly valuable, it helps us
      • to plan the work
      • to align our work with the problem that we’re trying to solve
      • to continuously improve our process through timely reflection
• The origins of this myth
  • A. The meeting culture was already there
    • Scrum Teams often have to attend MANY meetings outside of the regular Scrum events
    • Are the Scrum events really the problem here?
    • or does Scrum simply make the existing meeting culture transparent?
    • Are all these other meetings really necessary?
    • Or are they merely the result of non-optimal implementations of Scrum? With…
      • people being part of multiple teams
      • teams that are not really cross-functional (and have lots of dependencies)
      • Product Owners without actual mandate
    • This is where the role of the Scrum Master becomes important
      • help identify those meetings that aren’t necessary and eliminate them
      • help the organization find other ways to organize work that aligns better with Scrum, so that the need for additional meetings can be minimized
  • B. Poor facilitation of the Scrum events
    • If we decide to spend time on a Scrum event, it should be facilitated in a way that is respectful of that investment
    • In reality, most Scrum events are facilitated in a way that is quite boring
    • Good facilitation requires
      • focus on the purpose of the event
      • respect for the time-box
      • keep the conversations on-topic
      • create a safe atmosphere
      • promote open discussions, conversations and interactions
      • Energetic
      • Involve all
      • What should we have conversations about?
      • How can we have these conversations in ways that are more effective than just sitting around a table, listening to a couple of people?
    • Without proper preparation and facilitation, the events will be (and feel like) a waste of time
  • C. Part-time team members or people that are part of multiple teams
  • D. ‘Only sitting behind my laptop is work’ (or efficiency over effectiveness)
• TIPS - What can you do to improve the effectiveness and make them more enjoyable?

Manager’s schedule AND Maker’s schedule

• Manager’s schedule: