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:
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:
---
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.