One of the most confusing parts of getting started with Scrum is understanding the Scrum events and how to schedule those events.
This blog will give a brief overview of events and some pointers for scheduling and staying on track.
Early on in our Agile careers with Scrum, we found ourselves in meetings asking ourselves (and one another) “Now, what meeting is this?” There are 5 distinct events in Scrum (and one unofficial event we like to use called Backlog Refinement (or Storytime), and they’re defined below:
As per the Scrum Guide (the official and definitive guide on Scrum, which you should checkout if you’re interested in Agile and Scrum) by Ken Schwaber and Jeff Sutherland, a Sprint is defined as “a time-box of one month or less during which a done, useable, and potentially releasable product increment is created. ” At it’s core, this event is just an amount of time in which you’ll create product(s).
Most common and what we use-2 weeks
Work to be completed is planned and committed to in Sprint Planning. The ScrumMaster and the Product Owner work together to determine what priorities are important, but they only decide “what” work will be completed. The development team or team responsible for completing the work is who decides exactly “how” this work gets done since they’ll be “doing” the work, and they also help determine how much work they can take on.
Max of 8 hours for a 1 month Sprint
We usually have 2-3 hour Sprint Planning sessions for a 2 week Sprint
Sprint Review (non-official Scrum name: Sprint Demo)
The Sprint Review is a chance for customers (either internal or external) to see the product you’ve developed during the Sprint. Product is demoed in this event, and feedback is gathered, but no commitments to improvements or implementing feedback are made.
We usually hold 1 hour demos
The Scrum Guide says it best:
*The purpose of the Sprint Retrospective is to:
- Inspect how the last Sprint went with regards to people, relationships, process, and tools;
- Identify and order the major items that went well and potential improvements; and,
- Create a plan for implementing improvements to the way the Scrum Team does its work.*
We usually have 1 hour Retrospectives
Daily Scrum (non-official Scrum name: Daily Standup)
This event is meant as a check-in each day to cover these three questions:
- What did I do yesterday?
- What will I do today?
- Are there any impediments?
Backlog Refinement (we call it Storytime)
While this isn’t an official Scrum event, we adopted it because it helps us pre-plan our next Sprint. We use it as an opportunity to discuss the Backlog (which is just a list of priorities), and to look ahead for what may be coming.
While this isn’t an official event, there’s not recommended time, but we usually spend 1-2 hours in this event.
Lessons we’ve learned
Sprints can last anywhere from 1-4 weeks. The most common duration is 2 weeks. While we operate in 2 week Sprints now, we started with 1 week Sprints because a book we read Scrum: a Breathtakingly Brief and Agile Introduction suggested we do so. The reasoning behind starting with a 1 week Sprint is according to Sims and Johnson, it takes at least 6 Sprints to become fluent in the process, so by shortening Sprint length, you fail faster. And while it’s confusing and overwhelming, it was helpful. Here are some things we learned that hopefully will help you in implementing Scrum:
- Since we were in so many meetings, we were confused about the purpose. We made a cheat-sheet and carried it with us to all meetings to remind ourselves what the hell we were doing as we worked.
- You’ll fight. There’s no doubt. Since this is a very transparent way of working, and if you do try 1 week Sprints (which we HIGHLY recommend), you’re going to get sick of each other, you’re going to get sick of the process, you may want to box each other, but you’ll survive. And it’s worth it. Trust us.
- If you do fight, try not to do it during the Daily Standup. You want that meeting to be short (hence why it’s suggested you STAND UP). The Daily Standup is not meant to solve problems, but it’s intended to uncover problems if they arise: not more than a day goes by before impediments are uncovered and can be dealt with, but when you’re new, you’ll have the tendency to want to solve the problem in the moment. Set time after to talk.
- Something we heard about as a technique and have implemented and loved is showing appreciation for team members at the end of each Retrospective. Each member of the team gets the opportunity to acknowledge any other member(s) of the team for something they did well. Transparency can be difficult at first, and seeing into the ways people work can sometimes uncover inefficiencies, but assuming positive intent of the team and making time to acknowledge one another can help the growing pains and strengthen the team dynamic.
- It seems like a lot of meetings at first, we know; what we’ve learned over time, however, is since you spend time in all of these meetings, and the work is so transparent, it eliminates the need for other meetings like product updates, check-ins, or team meetings. It’s awesome, freeing, and gives you time back and eliminates the need for unnecessary meetings.
- The Daily Standup is most effective in the morning, and while no one person is required to “start” it, someone has to when they remember. It ideally should happen in person, but that isn’t always possible with distributed teams: if you are working in separate time zones, try out a tool like WebEx (with webcams on!), Skype, or explore asynchronous Agile add-ons to communication tools like Slack.
- When you forget to have the Daily Standup, stuff feels like it’s out of control. If we can stress anything, work through the tedious feeling you might experience when you first start standups–they are crucial.
- Originally we held Sprint Planning on Monday, Retrospectives on Friday, and the other meetings in between. There are a lot of Monday holidays in the US business world, and it turns out the last thing people want to do is talk about their feelings and how their process has been working on a Friday afternoon, so we switched major events to mid-week. (we’ll show that in our scheduling part below)
- Scheduling makes no sense at first, so that’s why we went analog and used a color-coded schedule like the one below (with pen, highlighter, and oftentimes, whiteout)
In the above example, you’ll notice Sprint A begins on Wednesday 6/6 and continues through Tuesday 6/19 up until the next Sprint (Sprint B) begins on 6/20. What was most challenging to schedule when we started, however, was Storytime (the pre-planning meeting for the next Sprint). So, that’s why color-coding a schedule seemed to help. You’ll see that even though we don’t get into the July schedule, a pre-planning meeting for Sprint C happens while Sprint B is still in effect. Something not on this schedule is the Daily Standup. On any working day–in our working world, M-F–we have a Daily Standup everyday.
While implementing this process seems like a lot of work up front, it’s worth it. In implementing your own schedules and Agile framework, if you have questions, challenges, or solutions to share, we’d love to hear from you! Feel free to leave a comment or send us an email.