How the Karmak eLearning Team Used Sprint Planning to Tackle Their Mammoth Project

By: Joe Healy & Ezzy SchesvoldThe Karmak eLearning team faced a mammoth project. We were in the process of revamping all 300individual 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 realisticdeadlines. The scope of the project continued to grow, seemingly out of control. We were strugglingwith buy-in, both at the subject matter expert level and executive level. We were also constantly inmeetings 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 IdeaSprint planning, also known as iteration planning, is a component of the agile software developmentmethodology that places an emphasis on teams planning for what they can commit to finishing over aset 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 greatsuccess, 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-weekincrements, 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 PlanWe decided three-week sprints were right for us. Our software development team uses two-weeksprints, but it’s less about picking the “right” length for a sprint and more about finding the length thatworks 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 whatthey’re currently working on and potential roadblocks, such as scheduled time out of the office, andestimates 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 aboutsprint 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 totrack an individual’s commitments for the sprint. Those can certainly be effective ways of managingworkload, but we found that we didn’t need to over-formalize this process and that we learned howmuch 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 movetasks 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, andsometimes 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 outother 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 coursesalong the way because it turns out that they were redundant? Or were they just simpler thananticipated?No matter the reason, these were now just more data points to take into consideration during theplanning meeting for the next sprint.Crucially, this allowed us to set a realistic deadline for the entire project. It was as simple as taking anaverage of how many courses we finished in a sprint and then extending that out as long as it wouldtake us to get through everything we had left to finish.The ResultsNow, 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 scheduledmeetings over every three-week period.
• We were able to provide accurate data on how much coursework we had completed in a setperiod, such as the last sprint, the last three sprints, the last quarter, the last six months, or thelast year.
• Our subject matter experts bought into the project like never before. We brought them into thesprint planning process, and they played a key role in shaping course organization anddevelopment, 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-sidedrelationship.
• Accountability among the instructional designers improved. When everyone on the team cansee your coursework commitments, you are more motivated to complete what you said youwould, and you’re also less likely to overcommit.

How to Get StartedPerhaps 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 haveeverything 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.