This book will help you write better stories, spot and fix common issues, split stories so that they are smaller but still valuable, and deal with difficult stuff like crosscutting concerns, long-term effects and non-functional requirements. Above all, this book will help you achieve the promise of agile and iterative delivery: to ensure that the right stuff gets delivered through productive discussions between delivery team members and business stakeholders. Who is this book for? This is a book for anyone working in an iterative delivery environment, doing planning with user stories. The ideas in this book are useful both to people relatively new to user stories and those who have been working with them for years. People who work in software delivery, regardless of their role, will find plenty of tips for engaging stakeholders better and structuring iterative plans more effectively. Business stakeholders working with software teams will discover how to provide better information to their delivery groups, how to set better priorities and how to outrun the competition by achieving more with less software. What's inside? Unsurprisingly, the book contains exactly fifty ideas. They are grouped into five major parts: - Creating stories: This part deals with capturing information about stories before they get accepted into the delivery pipeline. You'll find ideas about what kind of information to note down on story cards and how to quickly spot potential problems. - Planning with stories: This part contains ideas that will help you manage the big-picture view, set milestones and organise long-term work. - Discussing stories: User stories are all about effective conversations, and this part contains ideas to improve discussions between delivery teams and business stakeholders. You'll find out how to discover hidden assumptions and how to facilitate effective conversations to ensure shared understanding. - Splitting stories: The ideas in this part will help you deal with large and difficult stories, offering several strategies for dividing them into smaller chunks that will help you learn fast and deliver value quickly. - Managing iterative delivery: This part contains ideas that will help you work with user stories in the short and mid term, manage capacity, prioritise and reduce scope to achieve the most with the least software. About the authors: Gojko Adzic is a strategic software delivery consultant who works with ambitious teams to improve the quality of their software products and processes. Gojko's book Specification by Example was awarded the #2 spot on the top 100 agile books for 2012 and won the Jolt Award for the best book of 2012. In 2011, he was voted by peers as the most influential agile testing professional, and his blog won the UK agile award for the best online publication in 2010. David Evans is a consultant, coach and trainer specialising in the field of Agile Quality. David helps organisations with strategic process improvement and coaches teams on effective agile practice. He is regularly in demand as a conference speaker and has had several articles published in international journals.

Learn how to improve retrospectives and avoid stagnation, with fifty ideas designed to help you enhance and energise your continuous improvement effort. This book will help you get better outcomes from retrospectives and from any continuous improvement initiative. It will help you consider how best to prepare for retrospectives, generate innovative insights, achieve valuable outcomes, improve facilitation techniques, keep things fresh and maybe even how to have a bit of fun whilst doing it. This book is for anyone who undertakes continuous improvement of any sort, especially those looking to get better outcomes from retrospectives, either as a participant, facilitator, coach or manager of teams. We include ideas for people with varying levels of experience. So, whether you are just getting started with Scrum and retrospectives, or a veteran of continuous improvement looking to fine-tune or get new ideas, or if your retrospectives have become a bit stale and need re-invigorating, there are ideas in here to support you.

A practical guide to impact mapping, a simple yet incredibly effective method for collaborative strategic planning that helps organizations make an impact with software.

Summary Specification by Example is an emerging practice for creating software based on realistic examples, bridging the communication gap between business stakeholders and the dev teams building the software. In this book, author Gojko Adzic distills interviews with successful teams worldwide, sharing how they specify, develop, and deliver software, without defects, in short iterative delivery cycles. About the Technology Specification by Example is a collaborative method for specifying requirements and tests. Seven patterns, fully explored in this book, are key to making the method effective. The method has four main benefits: it produces living, reliable documentation; it defines expectations clearly and makes validation efficient; it reduces rework; and, above all, it assures delivery teams and business stakeholders that the software that's built is right for its purpose. About the Book This book distills from the experience of leading teams worldwide effective ways to specify, test, and deliver software in short, iterative delivery cycles. Case studies in this book range from small web startups to large financial institutions, working in many processes including XP, Scrum, and Kanban. This book is written for developers, testers, analysts, and business people working together to build great software. Purchase of the print book comes with an offer of a free PDF, ePub, and Kindle eBook from Manning. Also available is all code from the book. What's Inside Common process patterns How to avoid bad practices Fitting SBE in your process 50+ case studies =============================================== Table of Contents Part 1 Getting started Part 2 Key process patterns Part 3 Case studies Key benefits Key process patterns Living documentation Initiating the changes Deriving scope from goals Specifying collaboratively Illustrating using examples Refining the specification Automating validation without changing specifications Validating frequently Evolving a documentation system uSwitch RainStor Iowa Student Loan Sabre Airline Solutions ePlan Services Songkick Concluding thoughts

WHAT IS THIS BOOK ABOUT? This Book Is About the “Card” (User Story: Card, Criteria, Conversation) User Stories are a great method for expressing stakeholder requirements, whether your projects follow an Agile, Iterative, or a Waterfall methodology. They are the basis for developers to deliver a suitable information technology (IT) app or application. Well-structured user stories express a single action to achieve a specific goal from the perspective of a single role. When writing user stories, stakeholders knowledgeable about the role should focus on the business result that the IT solution will enable while leaving technology decisions up to the developers. Good user stories are relevant to the project, unambiguous, and understandable to knowledge peers. The best user stories also contain crucial non-functional (quality) requirements, which are the best weapon in the war against unsatisfactory performance in IT solutions. This book presents two common user story structures to help you ensure that your user stories have all the required components and that they express the true business need as succinctly as possible. It offers five simple rules to ensure that your user stories are the best that they can be. That, in turn, will reduce the amount of time needed in user story elaboration and discussion with the development team. This book targets business professionals who are involved with an IT project, Product Owners in charge of managing a backlog, or Business Analysts working with an Agile team. Author’s Note The term “User Story” is a relative new addition to our language and its definition is evolving. In today’s parlance, a complete User Story has three primary components, namely the “Card”, the “Conversation”, and the “Criteria”. Different roles are responsible for creating each component. The “Card” expresses a business need. A representative of the business community is responsible for expressing the business need. Historically (and for practical reasons) the “Card” is the User Story from the perspective of the business community. Since we wrote this book specifically to address that audience, we use the term “User Story” in that context throughout. The “Conversation” is an ongoing discussion between a developer responsible for creating software that meets the business need and the domain expert(s) who defined it (e.g., the original author of the “Card”). The developer initiates the “Conversation” with the domain expert(s) to define the “Criteria” and any additional information the developer needs to create the application. There is much to be written about both the “Conversation” and the “Criteria”, but neither component is dealt with in any detail in this publication. A well-written User Story (“Card”) can drastically reduce the time needed for the “Conversation”. It reduces misinterpretations, misunderstandings, and false starts, thereby paving the way for faster delivery of working software. We chose to limit the content of this publication to the “User Story” as understood by the business community to keep the book focused and address the widest possible audience. WHO WILL BENEFIT FROM READING THIS BOOK? How organizations develop and deliver working software has changed significantly in recent years. Because the change was greatest in the developer community, many books and courses justifiably target that group. There is, however, an overlooked group of people essential to the development of software-as-an-asset that have been neglected. Many distinct roles or job titles in the business community perform business needs analysis for digital solutions. They include: - Product Owners - Business Analysts - Requirements Engineers - Test Developers - Business- and Customer-side Team Members - Agile Team Members - Subject Matter Experts (SME) - Project Leaders and Managers - Systems Analysts and Designers - AND “anyone wearing the business analysis hat”, meaning anyone responsible for defining a future IT solution TOM AND ANGELA’S (the authors) STORY Like all good IT stories, theirs started on a project many years ago. Tom was the super techie, Angela the super SME. They fought their way through the 3-year development of a new policy maintenance system for an insurance company. They vehemently disagreed on many aspects, but in the process discovered a fundamental truth about IT projects. The business community (Angela) should decide on the business needs while the technical team’s (Tom)’s job was to make the technology deliver what the business needed. Talk about a revolutionary idea! All that was left was learning how to communicate with each other without bloodshed to make the project a resounding success. Mission accomplished. They decided this epiphany was so important that the world needed to know about it. As a result, they made it their mission (and their passion) to share this ground-breaking concept with the rest of the world. To achieve that lofty goal, they married and began the mission that still defines their life. After over 30 years of living and working together 24x7x365, they are still wildly enthusiastic about helping the victims of technology learn how to ask for and get the digital (IT) solutions they need to do their jobs better. More importantly, they are more enthusiastically in love with each other than ever before!

Improve Your Creativity, Effectiveness, and Ultimately, Your Code In Modern Software Engineering, continuous delivery pioneer David Farley helps software professionals think about their work more effectively, manage it more successfully, and genuinely improve the quality of their applications, their lives, and the lives of their colleagues. Writing for programmers, managers, and technical leads at all levels of experience, Farley illuminates durable principles at the heart of effective software development. He distills the discipline into two core exercises: learning and exploration and managing complexity. For each, he defines principles that can help you improve everything from your mindset to the quality of your code, and describes approaches proven to promote success. Farley's ideas and techniques cohere into a unified, scientific, and foundational approach to solving practical software development problems within realistic economic constraints. This general, durable, and pervasive approach to software engineering can help you solve problems you haven't encountered yet, using today's technologies and tomorrow's. It offers you deeper insight into what you do every day, helping you create better software, faster, with more pleasure and personal fulfillment. Clarify what you're trying to accomplish Choose your tools based on sensible criteria Organize work and systems to facilitate continuing incremental progress Evaluate your progress toward thriving systems, not just more "legacy code" Gain more value from experimentation and empiricism Stay in control as systems grow more complex Achieve rigor without too much rigidity Learn from history and experience Distinguish "good" new software development ideas from "bad" ones Register your book for convenient access to downloads, updates, and/or corrections as they become available. See inside book for details.

Anyone who watches the television news has seen images of firefighters rescuing people from burning buildings and paramedics treating bombing victims. How do these individuals make the split-second decisions that save lives? Most studies of decision making, based on artificial tasks assigned in laboratory settings, view people as biased and unskilled. Gary Klein is one of the developers of the naturalistic decision making approach, which views people as inherently skilled and experienced. It documents human strengths and capabilities that so far have been downplayed or ignored. Since 1985, Klein has conducted fieldwork to find out how people tackle challenges in difficult, nonroutine situations. Sources of Power is based on observations of humans acting under such real-life constraints as time pressure, high stakes, personal responsibility, and shifting conditions. The professionals studied include firefighters, critical care nurses, pilots, nuclear power plant operators, battle planners, and chess masters. Each chapter builds on key incidents and examples to make the description of the methodology and phenomena more vivid. In addition to providing information that can be used by professionals in management, psychology, engineering, and other fields, the book presents an overview of the research approach of naturalistic decision making and expands our knowledge of the strengths people bring to difficult tasks.