Gojko Adzic - Fifty quick ideas to improve your user stories

This book will help you write better stories, spot and fix common issues, splitstories so that they are smaller but still valuable, and deal with difficultstuff like crosscutting concerns, long-term effects and non-functionalrequirements. Above all, this book will help you achieve the promise of agileand iterative delivery: to ensure that the right stuff gets delivered throughproductive discussions between delivery team members and business stakeholders.

This is a book for anyone working in an iterative delivery environment, doingplanning with user stories. The ideas in this book are useful both to peoplerelatively new to user stories and those who have been working with them foryears. People who work in software delivery, regardless of their role, will findplenty of tips for engaging stakeholders better and structuring iterative plansmore effectively. Business stakeholders working with software teams willdiscover how to provide better information to their delivery groups, how to setbetter priorities and how to outrun the competition by achieving more with lesssoftware.

This book doesnt cover the basics of stories. We assume that readers know whatCard-Conversation-Confirmation means, what INVEST is and how to apply the basicstrategies for splitting user stories. This isnt the first book you should readabout user stories, if those terms are unfamiliar. There are plenty of goodbasic books out there, so read them first and then come back. Please dont hateus because we skipped the basics, but there is only so much space in the bookand other people cover the basics already well enough.

Unsurprisingly, the book contains exactly fifty ideas. They are grouped intofive major parts:

• Creating stories: This part deals with capturing information about storiesbefore they get accepted into the delivery pipeline. Youll find ideas aboutwhat kind of information to note down on story cards and how to quickly spotpotential problems.
• Planning with stories: This part contains ideas that will help you managethe big-picture view, set milestones and organise long-term work.
• Discussing stories: User stories are all about effective conversations, andthis part contains ideas to improve discussions between delivery teams andbusiness stakeholders. Youll find out how to discover hidden assumptions andhow to facilitate effective conversations to ensure shared understanding.
• Splitting stories: The ideas in this part will help you deal with large anddifficult stories, offering several strategies for dividing them into smallerchunks that will help you learn fast and deliver value quickly.
• Managing iterative delivery: This part contains ideas that will help youwork with user stories in the short and mid term, manage capacity, prioritiseand reduce scope to achieve the most with the least software.

Each part contains ideas that weve used with teams over the last five or sixyears to help them manage user stories better and get more value out ofiterative delivery. These ideas come from many different contexts, from largeinvestment banks working on internal IT initiatives to small web start-upsshipping consumer software. Software delivery is incredibly contextual, so somestories will apply to your situation, and some wont. Treat all the proposalsin this book as experiments try them out and if they help keep doing them.

There is only so much space in a book, and some of the ideas described deserveentire books of their own. We provide plenty of references for further studyand pointers for more detailed research in the .

If youd like to get more information on any of the ideas, get additional tipsor discuss your experiences with peers, join the Google group50quickideas.

There is, of course, one more important aspect of user stories: agreeing on theright confirmation criteria for testing. To prevent scope creep, we decided toput ideas about this topic in a separate book. If you are interested, head overto 50quickideas.com and grab a copy of FiftyQuick Ideas to Improve Your Tests.

Tell stories, dont write them

User stories are often misunderstood as lightweight requirements, given by thebusiness stakeholders to the delivery team. This misunderstanding leads tostories being collected in a task management tool, with a ton of detail writtendown by business representatives. Except in the very rare case where thebusiness representative is also a technical expert and has a great vision forthe product, this division of work prevents organisations from reaping thebenefits of user stories.

To make things crystal clear, if a team passively receives documents in ahand-over, regardless of what they are called and whether they are on paper, ina wiki or in a ticketing system, thats not really working with user stories.Organisations with such a process wont get the full benefits of iterativedelivery.

User stories imply a completely different model: requirements bycollaboration. Hand-overs are replaced by frequent involvement and discussions.When domain and technical knowledge is spread among different people, adiscussion between business stakeholders and delivery teams often leads to goodquestions, options and product ideas. If requirements are just written down andhanded over, this discussion does not happen. Even when such documents arecalled stories, by the time a team receives them, all the important decisionshave already been made.

Effective discussions about user needs, requirements and solutions becomecritically important with short delivery phases, because there just isnt enoughtime for anyone to sit down and document everything. Of course, even with longerdelivery phases documenting everything rarely works, but people often maintain apretence of doing it. With delivery phases measured in weeks or days, thereisnt enough time to even pretend. When a single person is writing anddocumenting detailed stories, the entire burden of analysis, understanding andcoordination falls on that person. This is not sustainable with a rapid pace ofchange, and it creates an unnecessary bottleneck. In essence, the entirepipeline moves at the speed of that one person, and she is always too busy.

Try telling stories instead of writing down details. Use physical story cards,electronic ticketing systems and backlog management tools just as reminders forconversations, and dont waste too much time nailing down the details upfront.Engage business stakeholders and delivery team members in a discussion, look ata story from different perspectives and explore options. Thats the way tounlock the real benefits of working with user stories.

Key benefits

Discussions allow business representatives not only to explain what they want,but also to ensure that the delivery team members understand this correctly.Misunderstandings between different roles are a major problem with any kind ofhand-over. Explaining a story face to face prevents problems from fallingthrough knowledge gaps.

The second benefit is faster analysis. When the entire team is engaged in adiscussion, functional gaps, inconsistencies and unclear requirements getdiscovered faster than when a single person needs to write down the details.