Software that doesn’t solve the real problem and address the real needs of its customers fails. The antidote to this problem is to design around the user’s story. A story is not, as some believe, a code word for a random and overspecified bit of work or requirement filed away to die in Jira. Instead, a “user story” is literally our User’s Story–a narrative describing our customers/users’ work, the problems they encounter, and the things they need to accomplish. It describes our user’s work, not ours. The User’s Story doesn’t tell us what to build. It tells us what problems to solve so we can collaborate on an optimal solution and build the best possible product (from our user/customer’s perspective).

In his workshop, you’ll learn the most effective way to develop high-quality software products in minimal time by listening to our user’s stories and leveraging those narratives to create an optimal solution at the conceptual, architectural, and coding levels.
You’ll learn how to collaborate with our users/customers to understand their problems (their stories) and build solutions to those problems in small increments, frequently releasing for feedback and then adapting based on that feedback to guarantee that our products actually do what our customers need. You’ll also learn how to model the domain architecture implied by the stories to create easily maintainable, easy-to-change code. Along the way, you’ll learn a bit about Ensemble (Mob) Programming, which we use for the hands-on exercises.

This workshop is all about creating software that delights your users.

You’ll learn:
* about walking skeletons and how to start with very small (revenue-producing) releases and build incrementally from there.
* how stories fit into the overall product with user-story mapping.
* how to capture stories using the “three C’s”: card, conversation/collaboration, and confirmation.
* how to make stories smaller so we can implement and deploy them very quickly to get user feedback
* how to plan around and organize stories effectively, with or without a backlog.
* how to use stories to improve business-engineering communication and prioritization.
* how to translate those stories directly into a domain-focused architecture.