Agile user story: As [a type of user] I can [do action with a program ] in order to [achieve a goal of mine].

Learning story: As [a category of learner] I can [do action] in order to [achieve a goal of mine].

The main difference is that agile is about adding capabilities to software while education is about adding capabilities to people. If only we could do the latter with simple coding — or perhaps not, given how that would be misused.

I didn’t see this as meeting in-the-moment needs. It’s more about thinking about skills at a smaller level, prioritized by learner-centered value.

Chris, ok, fair enough on the original version (yikes, but hope that was likely an emergent meme wherever). Like the user story & scenario, don’t quite get the original form so also don’t get the learning variant. Just think that learning something (and yes, it’s a continuum) might be a bigger scope than meeting an in-the-moment need, and perhaps harder to create small deliverables against (though discrete learning components, e.g. example vs practice, would make sense). Again, happy to be wrong.

Re MVPs for learning experiences: I think relevant agile concept is not a piece of code, but a user story (https://www.mountaingoatsoftware.com/agile/user-stories). User stories define bits of end user value.

The standard user story form “as a I can in order to ” adapts very nicely to learning: “As a I can in order to .”

There are criteria for what makes good user stories (http://guide.agilealliance.org/guide/invest.html) that probably map over to learning stories as well.

Note: user stories are not requirements, just tokens for conversation, and they’re too small for planning (I prefer scenarios for that: http://www.slideshare.net/KimGoodwin/storytelling-by-design-scenarios-talk-at-confab-2011). But they are good brick-level units on which to build, IMO.

Re paths crossing: would love to meet some day.

Chris, thanks for the historical context. What I meant by strictures is that the ‘minimum viable product’ for a learning experience is, typically, of more complexity than a particular code function. It’s likely at least a practice and some resources. Though we could of course develop components independently (e.g. the practice, then elaborate). Certainly welcome counter examples (he says, pondering an open ended question that subs for an entire simulation). My open question here is given the typical nature of code sprints, and factoring down to functions, what’s the learning experience equivalent?

Appreciate the interactions (Chris, given your comments, I hope we get to cross paths some time!)

Where agile was different was that it came from developers, who asked “OK, we know we should, but we don’t. Let’s debug. Why don’t we do what we should? What sustainable simple changes could we make in how we work that might fix those bugs?” Why don’t we write test code? We run out of time at the end of projects. OK, let’s try writing the test code first. Why don’t we meet for code reviews? We’re busy and meetings are hard to schedule. OK, let’s try programning in pairs. And so on.

Could you expand on “Learning experiences … have some stricture that keeps them from having intermediately useful results.” What stricture?

As for when to stop iterating, in agile the answer is whenever you say we need to stop. Fix the deadline and then adjust scope as you discover how things are going. I think that’s what you’re saying with picking something like 3 iterations, but the critical thing is for clients to understand that you can’t fix both time and scope, i.e., metrics to be met. One or the other. That’s the simple consequence or working on wicked problems like learning.