Story + PD: Richer stories contextualize skimpy Agile ‘user story’ Post-its

Part of a series at the intersection of Storytelling and Product Development.

As I’ve been sharing my curiosity in conversations and catchups, I always learn something new. I caught up recently with Jump alumnus Margeaux Bucher. She helped an eclectic office of project people at Jump stay organized and operating smoothly, including looking after our very intentional culture. 

Margeaux has been a certified Agile Scrum Master for several years. She’s worked with a variety of teams and organizations using Agile in digital transformations and software development projects, helping them transition to and adopt Agile. With experience she’s gleaned insight into management systems and culture, and how these can be supportive (or often, barriers) to successful Agile implementation.  She spoke with me from her home in Portland, Oregon, where she is also an avid reader, talented painter, and creative mother. That’s four contexts for story right there. 

I asked Margeaux about how she sees story used in her work context, particularly with “user stories and epics’ as a formal element in Agile.  She finds the thick descriptions and transcripts and interactions provide engineers with more insight and inspiration. Many don’t always ask for it automatically, however, more experienced teams do. 

A big thing about getting some minimum amount of context is that it helps make distinctions between needs and solutions.

People ask engineers to build features, which should be solutions to a need. When they get richer stories, it engages their creativity to come up with the many solutions, not just the requested one; and importantly, it allows them to better define the right solution. 

(Need-solution confusion is so common, my cofounder Dev Patnaik has been drilling it into his Stanford students for over 20 years.)