BT

InfoQ Homepage Presentations Make Your User Stories Riveting

Make Your User Stories Riveting

Bookmarks

Bio

Seb Rose has been a consultant, coach, designer, analyst and developer for over 30 years. He is a regular speaker at conferences and occasional contributor to software journals, a contributing author to “97 Things Every Programmer Should Know” and lead author of “The Cucumber for Java Book”.

About the conference

Agile Tour London is an annual conference which explores all aspects of agility and its adoption and implementation in a business environment. Packed with inspirational talks and hands-on workshops, Agile Tour London 2016 offers unmatched opportunities to learn from the best agile experts in the industry. Whether you are an agile newbie or been in the industry for years, this is the definitive agile conference you can't afford to miss.

Recorded at:

Jul 04, 2018

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Make Your User Stories Riveting

    by Christian Johansen /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Seb
    I've watched two of your presentations
    1) Make Your User Stories Riveting
    2) BDD by Example - Agile on the Beach 2014

    Very inspiring

    Did I get something wrong or do you suggest that we throw out user stories or was that just the original idea ? Because for me it seem s to be orthogonal to the concept of living documentation that you touch on in BDD by example. Namely that user storeis becomes implemented acceptance tests, that again becomes living documentation which is up to date with the actual implemented system.

  • Re: Make Your User Stories Riveting

    by Seb Rose /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, I do suggest that you throw out User Stories because they don't (or at least should not) form part of the living documentation.

    When stories were first used, back in the day, they were described as "a placeholder for a conversation." They were a way of deferring detailed analysis until we were fairly sure that we were about to implement a particular piece of functionality. The expected output of the conversation was the detailed requirements for the functionality which we were about to implement, spread over one or more smaller user stories. These smaller, detailed user stories' purpose is to allow us to prioritise and plan the delivery of the functionality in small increments.

    The way this process maps to the living documentation is that the requirements (a.k.a rules a.k.a. acceptance criteria) are captured at the top of a Gherkin feature file. The concrete examples are captured in formulated scenarios. The user stories themselves are no longer valuable, especially since many of them will have been very thinly sliced, "low-fidelity" stories. Each story builds upon those already delivered, making stories unsuitable for long term documentation.

    There was a time when every iteration ended with a "confetti party". All the user story cards that had made it to the DONE column were torn into small pieces and thrown up in the air, to the delight of the team. It was a long time ago. We were easy to please ;)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.