By: Joe Healy & Ezzy Schesvold
The Karmak eLearning team faced a mammoth project. We were in the process of revamping all 300
individual pieces of coursework in our learning management system, and frankly, we were struggling.
We were doing a poor job of measuring our output, which was expressed in our lack of realistic
deadlines. The scope of the project continued to grow, seemingly out of control. We were struggling
with buy-in, both at the subject matter expert level and executive level. We were also constantly in
meetings about the project.
We needed a plan to get us focused, to help us break up the project into manageable chunks, and to get us moving in the right direction. We decided to give sprint planning a shot.
The Idea
Sprint planning, also known as iteration planning, is a component of the agile software development
methodology that places an emphasis on teams planning for what they can commit to finishing over a
set short period of time. It shifts the thinking from being focused on when you can get the entire project finished to being focused on what you can finish in the next several weeks, and then extrapolating the data out to estimate a deadline for the entire project.
Our internal software development team uses this approach for their development tasks, with great
success, so why shouldn’t we see if some version of this same process would work for us?
Instead of looking at the entire 300-course project, we would now view the project only in three-week
increments, focusing on what each of us could finish during that time. Only at the end of each three-
week period did we stop to look at how the items in the sprint fit into the larger picture.
The Plan
We decided three-week sprints were right for us. Our software development team uses two-week
sprints, but it’s less about picking the “right” length for a sprint and more about finding the length that
works best for your team and your project. As long as your chosen length is short enough to allow you to realistically estimate how much you can get finished in that time, there is no wrong answer.
Every Monday, we kick things off with a sprint planning meeting, where each designer weighs what
they’re currently working on and potential roadblocks, such as scheduled time out of the office, and
estimates how many pieces of coursework they can finish in three weeks.
At first, it felt like we were using guesswork to make this estimation, but one of the great things about
sprint planning is that you quickly get a clear picture of what you can actually complete in three weeks,
making future estimates much more accurate.
Some organizations use concepts such as story points or something as simple as estimated hours to
track an individual’s commitments for the sprint. Those can certainly be effective ways of managing
workload, but we found that we didn’t need to over-formalize this process and that we learned how
much we could typically complete by just using data from previous sprints.
During the three weeks that follow each kick-off meeting, we used our internal tracking tool to move
tasks in each sprint between phases- in development, in SME review, in peer review, and complete. Any items that don’t get completed in a given sprint automatically roll over into the next sprint.
At the end of each sprint, we have a retrospective meeting, where we compare what we committed and what actually got finished. Sometimes it was more than estimated, sometimes it was less, and
sometimes the estimates were right on the money, but the benefit of this meeting was being able to talk about why.
If we got less done than estimated, was it because one or more designers got pulled away to help out
other departments or to take on urgent projects? Was it because someone was too aggressive in making his or her estimate? Or was it because some of the coursework in the sprint was more complex or involved than we assumed?
If we got more done, did we just underestimate our abilities? Were we able to eliminate some courses
along the way because it turns out that they were redundant? Or were they just simpler than
anticipated?
No matter the reason, these were now just more data points to take into consideration during the
planning meeting for the next sprint.
Crucially, this allowed us to set a realistic deadline for the entire project. It was as simple as taking an
average of how many courses we finished in a sprint and then extending that out as long as it would
take us to get through everything we had left to finish.
The Results
Now, our mammoth project is complete after working for the better part of two years, and with the help of sprint planning, we finished about two months ahead of schedule. That big win was the product of a bunch of small wins we collected along the way:
- We went from having status update meetings on a near-daily basis to having two scheduled
meetings over every three-week period. - We were able to provide accurate data on how much coursework we had completed in a set
period, such as the last sprint, the last three sprints, the last quarter, the last six months, or the
last year. - Our subject matter experts bought into the project like never before. We brought them into the
sprint planning process, and they played a key role in shaping course organization and
development, which also gave them a look into how the product would help them in their day-
to-day roles. In turn, they felt like a part of the project rather than objects of a one-sided
relationship. - Accountability among the instructional designers improved. When everyone on the team can
see your coursework commitments, you are more motivated to complete what you said you
would, and you’re also less likely to overcommit.
How to Get Started
Perhaps the best feature of sprint planning is that the only requirement is that you change your thinking about how you view a project. By virtue of having the project in front of you, you already have
everything you need to begin using sprint planning.
Here are some tips to get you started:
- Plan for the first sprint. Decide what meetings you want to have during the sprints and what you want to accomplish in each meeting. You can always correct your course later. We went from having five meetings every three weeks when we first started sprint planning to two meetings.
- Find a tracking tool that works for you. We started by using index cards, moved to a simple software system, and now use a more complex software solution that we share with our software development team. The right tool is the one that works for your situation.
- Be flexible. You may decide that two-week sprints are a better fit for you after you’ve already been through a couple of three-week sprints. You may find that having subject matter experts in your sprint planning doesn’t provide value. You may need to change your tracking tool. Know that this is not a failure, but rather, needed adjustments in a fluid process.
- Have fun. We gave each individual sprint a silly name and played music and made food to bring to our sprint planning meetings, which brought some life to what could have otherwise been a clinical process. Make sprints an event, not just a step on the way to completing your mammoth project.
—
Joe Healy is an Instructional Designer with Karmak, Inc. by day and a freelance sports writer by night.
Ezzy Schesvold is a Senior Instructional Designer with Karmak, Inc. In her spare time she loves to paint and write and perform music on her ukelele.