In this blog, co-written with Bill Cushard, we cover the process of scrum. In other blogs, and in our guide, The ServiceRocket Guide to Better Agile Course Development, we detail how to apply scrum to create courses.
Our goal is to encourage you to try scrum. Challenge yourself, because scrum just might improve your life and your career. With scrum, your projects can be organized and predictable. You can confidently take on any new project, from start to finish, no matter how big or intimidating it may at first seem.
Image credit: https://commons.wikimedia.org/wiki/File:Scrum_task_board_example.jpg
Scrum Definitions
The Scrum Team
Just like any project team, there is a scrum team with multiple roles.
Product Owner: This role owns the product requirements, understands the customer needs, and has the vision for where the product is headed. The Product Owner makes final decisions on what goes into the product (courses) and how it should end up. On our customer education teams, this role could be the training manager or anyone in your organization who owns the customer education function.
Team Member: Responsible for developing and delivering all or parts of courses that the team develops. On the customer education team, this might include instructional designers, curriculum developers, subject matter experts, editors, graphics designers, training coordinators, or anyone else responsible for building courses.
Scrum Master: The scrum master is the equivalent of a project manager who is primarily responsible for ensuring that the scrum process is followed.
In an ideal world, each role has at least one dedicated person. But in the real world, there could be overlaps. In a small customer education team, each person might take on a few roles. Don't get caught up having a person for each role. Focus on the responsibilities of each role and executing those responsibilities.
The Sprint
Scrum is made of sprints, which are defined time periods, during which a usable and potentially releasable product is developed. The purpose of a sprint is to define a concrete amount of work the team can deliver by the end of the sprint. The work should be a clearly defined product that can be shown to a customer as something that is, at a minimum, a prototype. In the context of a course, that could be a storyboard or a complete module, or a first draft of assessment questions. Whatever the deliverable, the sprint provides a defined time period during which the work gets done, and then delivered to a customer (internal or external).
Sprints are commonly two-week periods, but you decide the time period that works for you. Sprints can be weekly, monthly, or quarterly. The point is to not make your sprint so short that you cannot complete meaningful work, but not so long that stakeholders wonder what you are doing all day.
Projects have multiple sprints. For example, a course might take three months to develop. During that time, there may be six, two-week sprints that occur consecutively, at the end of which a clearly defined course is completed.
Sprint Planning
Sprint planning happens before (or at the beginning of) each sprint. The team gets together to decide what should, and can, get done during the sprint. This is an important process, because each team member is fully in charge of what they commit to in a sprint; not the product owner and not the scrum master. Each team member owns what they commit to. Scrum works so well because team members own their work and how much they commit to for each sprint. A sprint planning meeting is generally a process of reviewing everything that could be done, and then narrowing down to what should and can be done in the sprint.
Once the amount of work is determined, the work for that sprint is locked down. No other work should occur.
We know what you are thinking, "Is that even possible?" It is. And it all comes down to the scrum master.
The scrum master is the gatekeeper, keeping all unplanned work out of the sprint. While there will often be escalations and last minute changes, the scrum master reviews requests and makes sure there is a darn good reason before allowing the team to work on them. The focus is to keep the sprint focused on planned work. The scrum master fights against the unplanned work ensuring it is kept out of the sprint.
The Stand Up
The stand up is a meeting held each day during a sprint, with everyone on the scrum team. The meeting is short. Short enough that standing during the whole meeting doesn't feel too long. Meetings last at most 15 minutes, and are ideally held in the same location and at the same time each day. During the meeting, each team member answers the following questions:
What did I accomplish since the last stand up?
What I will accomplish by the next stand up?
What is blocking my progress?
Stand ups keep the team in sync and allow for quick course corrections. These meetings are run by the team, for the team. If a course developer commits, "I will accomplish the learning objectives by the next stand up," everyone knows that at the next stand up, she will say whether or not she finished her task. Scrum teams are more collaborative because sprint commitments are to one another on the team, and not to a distant manager or customer.
If the course developer shares at the next stand up that her progress is blocked, then it's the role of the scrum master to help remove the blockers. With regular stand ups, everyone knows what's going on. Issues are addressed immediately, and the project is more likely to be successful.
The Retrospective
The retrospective meeting occurs at the end of a sprint. During the retrospective, the team reviews the outcome of the sprint and asks two basic questions:
What went well during this sprint?
What could we improve on for the next sprint?
The retrospective is an opportunity to learn from each sprint, with the purpose of estimating better for the next sprint. When you first start using scrum, you usually find that not everything committed gets accomplished. Why might that happen? We generally overestimate what we can deliver, and under-estimate the urgent tasks and interruptions that occur every day. We find it difficult to say "No," when people ask us do to things, and we end up working on those requests instead of forging ahead on our sprint commitments.
This is normal. And this is why the retrospective is so important. It is a continuous learning process, giving the team a chance to pause and admit, "I did not plan well. I took on too many tasks, and was interrupted by the VP of Operations who needed an urgent report." The team could respond, "OK, since you create reports for the VP of operations every week, you should plan less work in the sprint. Plan only the work you can do in the sprint." Or the scrum master might say to the VP, "We need to find another way to run your reports because our team needs to focus on this project."
The next sprint should be better because you either commit to less work and actually finish it, or unplanned distractions are removed so you accomplish more in a sprint. This does not alway happen perfectly, and that's why a retrospective is done frequently, in a process of continuous learning.
The Backlog
What's a backlog got to do with scrum? Plenty. A backlog is an un-prioritized list of work for the development team that is derived from the roadmap and its requirements. It is your ultimate "to do" list, with all the un-started tasks and ideas related to your project. The scrum difference is that you don't just work through the tasks. Rather, the scrum team pulls work from the backlog, as there is capacity, and assigns the tasks iteratively at the beginning of each sprint.
Backlogs usually go up and down in size. Work is assigned and completed, and more tasks are added to the backlog. Sometimes backlogs grow to be overwhelming because they include potential deliverables, including "someday maybe" items and other wild ideas. The scrum master needs to be intimate with the backlog to help determine which tasks belong to which sprint. As your team comes up with new ideas, make sure they don't already exist in the backlog.
You love (or should love) your backlog because it takes the pressure off of having to do everything Now! Instead, when a new idea comes up, just add it to the backlog. Don't worry about when you should work on that task. That's for sprint planning. Each sprint planning meeting is an opportunity to evaluate what's important to work on now, pull those tasks out of the backlog and assign them to the current sprint.
Get Started with Scrum
We suggest you begin scrum by applying what you learn here. You might be thinking, "That's it? Scrum is so clear to me now. When do I start my next project?" Or, you likely have lots of questions. For now, keep it simple. You will gain experience, and expand your understanding and application of scrum as you go. Of course there's a lot more to scrum. We provide references to explore in our guide The ServiceRocket Guide to Better Agile Course Development.
In the next blog, we apply the scrum basics to the context of a course design project.
And just in case you missed it, the first blog in this series is called, Five Reasons to Use Scrum for Course Development.
This article originally appeared on the Learndot blog on July 5, 2017, and is co-written with Bill Cushard.
Comments