Make me write a book and get it for free

I’m thinking of writing a new book, but I need a bit of peer pressure from you – so make me write the book and get a free copy.

Update on 20 Jan 7AM GMT: 53.4% book offers taken

I’ve worked with several teams last year that had reasonably good tech practices, but things coming into their work stream were not defined well, not split well, not valuable enough in isolation, and generally not the kind of user stories that give people the big benefits that they expect. Applying a few small changes to the way they manage user stories made a huge impact on the actual outcomes of their software delivery. This got me thinking that perhaps this is a wider problem and other teams could benefit from the ideas we applied. So I’m thinking about writing a book about that. I want to write about how to define better stories, how to spot and fix common issues, how to split them so that they are valuable but small, how to deal with difficult stuff like cross-cutting concerns, long-term effects and “non-functional” requirements, and above all, how to get the promise of agile and iterative delivery by ensuring that the right stuff gets discussed and agreed between delivery team members and stakeholders.

Before I jump into a few months of writing, I’d like to know if I’m right or wrong thinking that other people out there have the same issues. This is where you come in! So here’s the deal: if the situation I’ve described sounds familiar, and improving user stories would potentially make a big impact on what you deliver, pre-register for the book and if 5K people do that in January I’ll write it, and you get a free (ebook) copy.

The working title is “50 Quick Ideas to Improve your User Stories” – check out the 50 quick ideas twitter stream for a sample. I’m planning to turn those one-liners into a book similar to Impact Mapping, both in terms of visuals and writing style, packed full of practical advice to try and lots of references for further research.

I’ll use LeanPub to gauge interest and publish the book drafts as I’m working on it. So if this is interesting, head over to LeanPub and sign up for the book. I’ll keep the price free until the end of January or until 5K people sign up. If we reach that number, my New Year’s resolution will be to make another great book! If you know anyone else who could benefit from the book, please share this page with them.

I'm Gojko Adzic, author of Impact Mapping and Specification by Example. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter. Join me at these conferences and workshops:

Product Owner Survival Camp

Specification by Example Workshop

Conference talks and workshops

43 thoughts on “Make me write a book and get it for free

  1. A book that helps teams move from Impact Mapping to Specification by Example would be enormously valuable and provide a framework for BDD end to end. Please do it!

  2. This is fantastic! My top priority for 2014 with the teams I’ve been coaching is how to write good user stories and acceptance criteria. They’ve been getting by with so-so stories, and as the teams are learning how to do BDD to build up automated tests and the business is having to make really hard decisions about what work needs to be first, the need for good, valuable user stories is huge.

  3. Splitting the stories is one of the major problems that our teams face. So yes practical advice on how to write user stories and how to split them into smaller user stories would be great.

    Thanks,
    Antony

  4. Hi Gojko
    Teams I run into definitely have difficulty properly organizing and describing the right thing to build. What I’m not so sure about is whether focusing specifically on user stories is the answer, unless you plan to tackle the idea “if we could only write our user stories better, all will be solved.”

    Issues with user stories are certainly a symptom, not sure if they are the root cause. I think it more has to do with teams having a clear idea of what they are trying to build and why, alongside with an understanding of effective ways to describe that information. One issue with user stories is trying to make them more than what they really are.

  5. The book will be valuable because in many cases the requirement needs to be broken down so that the finer details are included in the story. The details matter. It would be helpful to provide samples of some good user stories with an explanation as to why they are considered to be good. Thank you.

    Happy New Year!

    Carla

  6. Gojko samo napred (just go ahead),

    I am currently struggling to start an experimental project and I am trying to use some tools: speclog (impact and story mapping) that connects to Visual Studio Online (ex. TFS Services) or (TFS on-premise, JIRA) and helps product owner define high level requirements/features of the system and specflow and specrun can then define executable specification once develper provides ATDD tests in NUnit and run it during a sprint.

    It would be a good thing to establish mini groups (experts in these tools) in .NET, Java, Ruby and other languages that support Gerkin language that will show an integrated experience in a series of screen-casts and providing an open source solution in targeted language based on your specification by example idea and clarification on proper terminology usage.

    I am researching how to split my requirements using a hierarchical items like:
    epic/feature/sub-feature/user story and there are other items that I would like to incorporate like themes, capabilities. (I am guessing epic == capability and theme == [tag name])

    For now I like how John Ferguson Smart explained in section: 7.3.2 on this page:
    http://thucydides.info/docs/thucydides-one-page/thucydides.html#_setting_up_your_project_and_organizing_your_directory_structure:
    + src
    + test
    + resources
    + stories
    + grow_potatoes [a capability]
    + grow_organic_potatoes [a feature]
    – plant_organic_potatoes.story [a story]
    – dig_up_organic_potatoes.story [another story]
    + grow_sweet_potatoes [another feature]

    The above standard structure for thucydides uses three levels: capabilities, features and stories, however it can be changed to: epics, theme and stories
    This html report (as a result of running ATTD tests shows the standards breakdown):
    http://wakaleo.com/thucydides-sample-reports/capabilities.html

    So a good idea to write your next book.
    Rad

  7. This will be definitely needed. Given it will be “to the point” as Impact Mapping it will easily succeed “Agile Software Requirements” in every team (and people might actually read the book)

  8. it’s crazy but yesterday i had a talk with some colleagues about how deliver the most value instead of only deliver functionality, I’m really excited about this your new book XD

  9. For sure it’s important.

    It will help and will be a useful “tool” in building the right thing.

  10. Hi Gojko,

    In my team It’s a problem with estimating big user stories. For example, we estimated story in 13sp. Then decided to split it into several smaller stories and estimate them again. So we get 19sp in sum. It was underestimated.
    It’s a problem to be precise in estimating for the big stories. On the other hand splitting into several smaller not always means that stories will be independant and can be done separately.

  11. Hi Gojko,
    that would be a great idea!
    I personally just started to work SCRUM and for sure such work could help us a lot. Looking forward to get it soon!!!
    Thanks in advance

  12. User Story formats and best practices are still sort of a bit standardized. What is an epic, what is a user story, what are the rules to follow when transforming a user story in an epic etc. Non-functional requirements and UX referencing would also be very helpful to learn about.

  13. Looking forward to this one. Of course, like many teams we need to make our user stories better and more useful to our clients and us. Good luck with this book! Irja

  14. Gojko,

    Another great idea that is definitely needed.

    We have faced numerous issues with splitting stories and maintaining quality and consustency.

    Carlos

  15. Yep… story breakdown, story splitting, story mapping… drives pretty much everything, but most teams I encounter aren’t good at it and don’t have the patience to deal with it, because it’s hard.

  16. We need this book yesterday. Even with the right user stories to develop, we still face the headache of splitting and fitting them into iterations, not to mention those cross-cutting and non-functional requirements. It is sometimes difficult to ignite collaboration with users concerning this type of requirements.

  17. I’m looking forward to the book!

    Most of what I’ve read so far about writing user stories requires pretty magical circumstances.

    Please consider throwing in some examples where the landscape might not be changeable, but user stories might make things better all the same.

    Also, hoping very much for a reappearance of the three amigos illustration from Specification by Example.

  18. This book of yours would be a wonderfully useful for developing great products / applications / systems.

    I am looking forward to figuring out how it would relate to other interesting ideas like BDD, clean architecture, domain-driven design and lean start-up.

  19. If you could provide some real life examples in splitting the stories and benefits attached to it, that would really help the teams. Large size stories are always a problem in terms of estimated points , but when split into smaller stories the size of the stories varies. Please also focus on Non functional Stories in your examples.

  20. The problem seems familiar and widely spread. Although, I’m feeling quite uneasy about addressing the problem as a problem with “managing user stories” or becoming better at splitting them. In the contexts I’ve been working in, when user stories (or what ever you use to remember what to build next) are off, it’s because the people who can contribute to the full set of perspectives needed to build a great product don’t work in conditions where communication and learning can be as effective as it should. IMO it’s a matter of managing the system, not user stories.

  21. Hi Gojko
    This sounds like a hugely valuable book. Go for it! Looking forward to reading it.
    All the best
    Nick

  22. Hi Gojko,

    Sure You’re right ! Go Go Gojko Goooo !
    it will be a kind of “Impact Storying by Example” useful book :)
    I wish you all the best for this new year.
    Alain

  23. Gojko,

    As the Story is the very important entity of the development, this topic already created interest and its going to be valuable to very team regardless of what practices they will follow.

    Looking forward to it.

    Arun

  24. The non-functional requirements part is particularly interesting to me. The other thing I’d be especially interested in is whether it’s possible to apply the same ideas and techniques to improve poorly-written bug reports (e.g. coming from 3rd party testers).

    I’d be happy to test-drive any of the ideas to give you feedback on how they work in a services company (as opposed to a product company), and/or help by proofreading the book.

  25. Hi Gojko ,

    Our team has defined 12 functional areas in a software factory model. We receive the epic user stories from our clients and decompose those into vertical user stories for each of the functional teams. As above, managing non functional requirements, and dependencies across the vertical teams are key issues. Regards, Jon

  26. I really look forward for your book. Please let me know if I can help you in any way.

    Regards
    Savita

  27. Hi Gojko,
    looking forward to this book-to-be; what i consider as problem is that it is difficult to embed non functionality in user stories. You see the old problem of incorrect requirements is replaced by the new problem of incorrect user stories. A challenge to improve.

  28. Dear Gojko,

    More information about agile requirements engineering is certainly welcome.

    Best regards,
    Jeroen

  29. Gojko,
    Having read SBE and BTCG, it would be great to see a book on story improvement in the same vein. I appreciate the numerous collections of real world anecdotes that the above mentioned books contained. I’d like to see how stories were actually split and what trade offs were made in doing so – the whole INVEST thing doesn’t work for me because I’ve not seen a credible sample set of stories that actually fulfill each letter in INVEST.

    Do us all a favor and write the book!

    Cheers

    Pete

  30. Hi Gojko,
    I really look forward for you book. In order to start with testing as soon as possible the right and well described stories are mandatory.
    Please do it!
    Kind regards,
    Filip

  31. Hi Gojko,

    I guess first tip would be that user stories are not the end state, but the beginning of a conversation to have with your client ;-)

    In my opinion it’s an art to write good user stories. I’ve seen teams that almost split the user stories up to single scenario’s and I’ve seen teams having user stories as big as epics. The range can be very wide. I think tips in your book might help set the bandwidth of how big/small user stories could be.

    I’m looking forward to read, review and maybe even contribute to the tips and books.

  32. Hi Gojko,
    You hit the mark. I am very curious of your ideas on how to answer the question “how to write user stories that really helps”.
    I am very happy to share my experiences of specification by example workshop in my organization.
    Kind Regards,
    Matthias

  33. Hi Gojko,

    We have tried various different ways of writing user stories and the level of information that should be in them but failed everytime. Would really appreciate help with this.

  34. Hi Gojko!, I agree 100%, no pictures, no key-examples in specification, missing break down from abstract to concrete -> lots of changes/clarifications and bugs.
    Having this ready would help a lot. Also please add links to basic, raw approaches not to get lost in fine tuning tricks; some teams are still far away from fine tuning. Thank you! Joe

  35. Hi Gojko, It’s definitely a book that we need, all of us.
    I would be glad to help if you need it.

    Fred

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>