Here is how I could relate to my own approach towards e-Learning solutions and SCRUM teams.
1. Limit choices to client for accepting and appreciating your solutions better: Do not show too may design options of screens. Create maximum of 2 and adapt screens to not more than 4-5 templates per course.
2. Provide concrete consequences of each decision or change or requirement to drive projects towards closure. Make it more visual and real than writing documents and pushing more and more descriptive text.
Make weekly charts on budget and schedule burn and forecast. Use it to iterate on impact of every request on schedule by making what-if scenarios to drive the acceptance on a holistic level. Create a minimal working proof of concept to iterate on the working.
3. To me this is important : Categorization. You can handle more categories than choices as categories help you to tell them apart. This is critical to understand why metadata is important in web world. Why we should assign semantics and leave a trail of our own synthesis to make web world more intelligent. So categorize your options and limit choices within each category. Create a short team and project vocabulary that is distinct and has unambiguous meaning. Apply folksnomy and taxonomy in communications so that it is easy to index and refer it from archives
4. Condition for complexity. Gradually introduce new features and move from simple to complex. Introduce one/few features at a time in solutioning world. A reason may be why niche tools that accomplish one task well than multi-approach tools could be why we stick to the app and become loyal users for a long time.
When you introduce a new interactivity, animation, new process, a revision to an existing priority, allow and give sufficient time for its acceptance. Do not rush on releases or changes in a train mode. Rather bursts of releases at predictive intervals enables to understand changes better.
A great use of time watching this video. Highly recommend it.