SCRUM based estimation: My learning from an e-Learning RFP

Recently I had the experience to estimate an e-Learning course development project based on SCRUM.

Usually I do a bottom-up feature and asset level estimation and the results are more accurate for planning and nailing scope in proposals. This is pain staking and in absence of lot of inputs, I need to rely on best judgment and use collective intelligence of team to identify and scope them. But it has always been worth the efforts. I then tally them into a Gantt based project plan to identify dependencies and factor in schedule and efforts for lead and lag times between teams and tasks. This adds up the cushion to handle project delays and exigencies profitably. Surely, Gantt based estimations shoots up the estimates because of the time the resource gets blocked in non-working times. Then there is a middle ground decided by bosses based on risk factors to ensure there is a winnable proposal.

For first time, I did a SCRUM based resource loading estimation in a recent RFP. I was sure that it is going to hit the roof. Because the initial understanding was that it is another way of resource forecast estimation in a new fad word (just a variation of Gantt based model that I am used to).  How wrong could I be ?

The beauty of SCRUM is that the estimation can be done both ways.

1. Estimation through user stories (essentially a bottom-up estimate technique) OR
2. Estimation through SCRUM team composition (Resource based estimation)

And when I used SCRUM for first time, both models, surprisingly gave close match results. Upon analysis, I realized that SCRUM premise and success is in the way idle time gets minimized. This, otherwise gets factored in resource allocation and estimation. Plotting the tasks and resources in Gantt mostly shows that utilization of resources optimally is a big challenge and is a trade off with other parameters either schedule or add in more people to finish few tasks so that dependent resources are ramped up on time.

 The foundation in SCRUM teams is that in a Sprint there is no idle time. There are schedule buffers, to account for waiting times between dependent tasks, just in case of a need. With Kanban use, there is always a queue of tasks/features and there is progress of the queue across columns. Each member is expected to move the queue from head to finish by owning their work. This is akin to a conveyor belt of task supply that gets picked by resources in a continuous stream. While tasks may wait for resources, it isn't always the other way around. This is profound. Because task waiting to be picked up doesn't expand the efforts or consume additional resources.

This is the change that SCRUM teams are advantageous about. There isn't a fixed flow. If there is a dependent task that is delayed or not available, instead of waiting for the assigned one, pick up one from the belt that is ready for your work. Thus idle times are minimized. Hence resource based SCRUM team estimation planning nearly and accurately maps to the bottom up estimation.

Further, SCRUM promotes high level of camaraderie between members to assist each other in finishing tasks that are taking longer by a single person. This too makes it possible that there is no waiting or lag time for resources to wait for work.

Bottom up estimation is the default model of SCRUM working. You estimate time and efforts per user story which then rolls up to a final shippable product estimation. So if a task or a feature is in a conveyor belt and not picked up, it just means that productivity has improved in teams. This then gets factored in successive Sprints thereby reducing the waiting times for tasks to be moved in Kanban card system.

Further, clients who are savvy about SCRUM or if you had done a workshop for the clients on SCRUM, you are bound to get good information upfront for estimation. Instead of assumptions, you can readily use user stories to base your budgeting and estimation models.

Sounds great, isn't it. Come onto SCRUM bandwagon and you will realize the marvels of a simple technique that answers age-old problems in estimation of e-Learning projects.

SCRUM and SCORM: A compelling case for adoption in e-Learning projects

Be it
1. An LMS customization and implementation
2. A new Product Creation
3. An e-Learning course development

SCRUM snugs well in all e-Learning implementations.This post is to iterate my thoughts on #3 above.

Most e-Learning course development contain inherent ability to package and publish the output as a SCORM package. For this post, I wish to request my readers to understand SCORM as a course asset model that allows to slice and dice courses into independent small size units called as "SCOs". SCOs have a great importance in reusability, durability and configuration across multiple learner groups and can be packaged across multiple learning modules. This is the benefit of SCORM apart from making it available across multiple LMS that support the specifications by allowing interactions between the courses and LMS.  SCORM makes for a great way for course designers to think in terms of packaging and easy access.

Where SCORM does not specify a way of execution, SCRUM fills the gap to showcase that execution of SCOs in Sprints makes for a better experience for clients and project teams alike.

e-Learning course development mostly follow a flavored variation of ADDIE model (which is likened to waterfall software development). My experience, thus far, has been that Instruction and Visual Designers thinking is always top-down ("AD" phase in ADDIE). Think of course at large, break it down as MLT (Module-Lesson-Topic) structure and then define SCO level. Then start work at SCO level based on templates, guidelines defined at high level. This is not wrong at all. This has been working well, so long until SCRUM changes the paradigm.

Top-Down design thinking has its merits. You define consistent writing styles, Instructional approaches for content treatment, color palettes, Interface elements, determine the navigation flows and drill down from overall business objectives to atomic level terminal objectives. This established upfront leaves developers and writers to publish courses with ease.

In this approach, when you request for a change to better, it becomes a limiting factor. What is good to digress becomes a one-off case or a work around. What is the ideal treatment style suited to a particular SCO, becomes a change request if not factored in the earlier design phase. What is required as a logical extension but not factored in earlier analysis phase becomes phase 2 or version 2 of the project. For larger implementations, beyond 3-4 months, a stagnant document driving the development suffers from dull teams executing with hand and not with brains. In many cases, the relevance becomes obsolete.

Every designer knows that although you arrive at design using a top-down approach (if done so), it is always an aggregation from bottom-up that makes real sense. A collection of terminal objectives satisfy a learning objective, a collection of learning objectives satisfy a business objective. We call them "Roll Up" objectives. From course standpoint too it is an aggregation model that makes meaning for ROI to training managers. Consumption and mandatory access of learning units aggregates to determine the project priorities and these in turn define the budgets for training. (However, still budgeting is a yearly top-down affair).

The definition of SCOs is left to course designers way of sizing the content and many a times based on the limitations of LMS/business requirements within confines of SCORM.  So designers either get to treat the entire course as SCO or a Module or really treat small topical units as SCO. In practice, there is no right or wrong approach in determining what is considered to be a SCO. 

Consider the case of users and learners for whom the whole industry strives for best experience. Users  knowledge is an aggregation of multiple learning units and past experience and learning that lets them perform better. It never happens to have a direct one to one correlation between learning a course and improvement in performance. It is an aggregation of learning from multiple sources that aids and betters performance. It is multiple insights from learning and their application that a job gets executed well. 

SCRUM comes around as a more meaningful approach towards design thinking and sizing of SCOs. The primary reason is that SCRUM at its fundamental level delivers value by aggregation. A collection of user stories determines a SPRINT, Every SPRINT delivers a shippable product. A collection of SPRINTS allow for successive iterations towards the desired goals.  Every Feature is prioritized and iterated in multiple SPRINTS thereby delivering maximum value while keeping overall vision in mind.

For commissioning any project, you need to have an intent (Vision) at highest level. But beyond that, every big thought is written down  and broken down to finer details as shared (user) stories. (in e-Learning terms SCOed). This allows for better design thinking at shared (user) story/SCO level and applying the patterns common across SCOs/user stories that unifies than homogenize the entire course.

Thus when SCORM meets SCRUM you get to see an exceptional output which retains the localized and unique customizations required at SCO level, while larger part of design is driven by commonalities across SCO units.  So instead of homogenizing SCOs as is done in top-down version, thereby bringing in monotony in treatment, you get to unify by applying designs that work at SCO levels, making SCOs truly stand alone as an independent package.

Does this mean each shared (user) story is a SCO. Possibly yes. But the flexibility is at designers desk. However, common sense dictates that you will not make a larger SCO than user stories.

 I am realizing the merits of this approach in my current assignment. Looking at design parameters at SCO level and rolling it up, gives far greater freedom to designers, writers, producers to improvise on the final output quality. SCO is the access point where users spend most of their time. This is where they will make opinions on your work.  This is the moment of truth for users to get maximum worth for their time. This is what business managers will eventually learn that their benefits are derived. Hence focusing on them that SCRUM greatly emphasizes on, is a better approach.

Welcome SCRUM to your e-Learning projects development and am sure of far greater productivity, happy development teams, clients and users.

Let me know your SCRUM and SCORM story.
 

SCRUM: A better method to manage Flux

You have an idea. You can only throw a few pages (say, less than 5) about the concept. You need to drive down but need a navigator help. You are sure it can succeed when you dive in deep to make the idea a better proposition collectively.

You need inspiration from like minded people, time to acquire intelligence from your sources and to have a notion of success, develop it to see some action.

You may want to cut down your losses at some point, change directions, move around pieces of your idea/work in a different sphere, or get a new idea that transforms the current work for a better scale.

You may want to pause, go for funding, travel for roadshows, be a change angel and find what your critics, cynics and competitors think, say and act. You would want to move down a feature and include a fresh and new thought to get it to marketplace early.

When you want to start small in a dream big project or divide work into smaller chunks, SCRUM is a great way to queue up work and get them moving to finish. All of the above is feasible due to possibilities with following SCRUM features.

1. With Sprint planning and Timeboxed iterations, you can refine, rewrite, replay, re-configure and pay for what your immediate goals are. Not to stretch to touch the horizon.
2. With Shared Stories (better to call it this way, because you are not the only one to write it) and Sprints, it is easy to see early outcomes and refine the language to promote them better. You get to see the linkages not previously envisioned and hence add it to a long list of shared stories written from users view. They leverage the past experience, existing products and licenses that can make your reach to idea transformation faster.
   
3. With Burndown charts and impediment logs, you get to know the roadblocks and hold a tighter control on the investment purse.
4. With Stakeholders meetings, Sprint stand ups  and Sprint Retrospectives, you continuously improve on the service, timeliness, productivity and product quality.

So isn't SCRUM a better way to manage Flux ?

Learning ID Theories

This is my attempt to collect all links from where I gained the knowledge in a single archive. Help me build this collaboratively. It is easy.
1. Click the request invite button in the popplet. Once you have access code, register yourself and then click this Popplet link.
2. Add nodes and move them around.
3. No need to save. It auto saves and check back in the blog that your work is getting reflected.
4. In case of any issues, drop a note via comments and we will fix it together.


View the larger Learning Map here




Important:
1. Ensure copyrights are respected.
2. Give due credits to site owners for their originality.
3. This is an experiment. So, if any one found their site content copied without permission, notify me in comments section and I shall pull it down. Thanks!!

Disclaimer: I am a user of Popplet service, just like you. So any bugs, feedback on Popplet system should go to them directly.

Importance of SCRUM

You cease to compete if you don't SCRUM.

A huge investment for a great product gets built

incrementally, iteratively, intelligently and importantly 

1. Stay ahead with lots of good features according to changing trends
2. Allow time to listen in to users
3. Prioritize scope and tell stories that can sell.

A dawn of realization happenned when I saw this in the product demos at my client site.

SCRUM is a promise that allows you to do well, keep the project health well and stay fit with all stakeholders expectations.

Challenges for Instruction Design

View the larger Learning Map here