The book "User stories. The art of agile software development »
User stories are a method of describing requirements for a product being developed. The book tells how to properly use this technique to focus on the task and the wishes of the client, and not to spray on the implementation of secondary functions. Jeff Patton shows how this approach not only accelerates and systematizes development, but also improves mutual understanding in the team.
The author told how to avoid the maximum number of misunderstandings associated with the use of stories in the development of software using Agile and Lean methodologies.
Quite a lot of organizations have already implemented Agile and Lean methodologies, therefore, it is quite possible that you have already managed to fall into one of the traps that arise due to a misunderstanding of the concept of stories. Here is some of them.
• Because stories let you concentrate on creating small pieces of software, it's easy to stop seeing the whole picture . The result is a typical Frankenstein product, for each user of which it is obvious that it consists of disparate, unrelated parts.
• When you work on a product of significant size, creating small particles one after another makes people wonder when you will finally finish and what will be the result . As if you are a builder.
• Since the main concept in the concept of stories is discussion, people often forget to keep notes . As a result, the subject of discussion and the agreements reached are forgotten.
• Since good stories assume acceptance criteria, we focus on defining these criteria. But this process and the description of the product being created are not the same thing. As a result, the team cannot finish the planned work in the scheduled time .
• Since good stories should be written from a user's perspective, but there are many aspects that the user simply does not see, team members say: “This product has no users, so user stories are not suitable here.”
If you have already fallen into one of these traps, I (the author) will try to clarify all the
misunderstandings that caused them. You will learn how to evaluate the full picture, productively discuss the goals and objectives of users and create good software.
For you, of course. Especially if you already bought it. I believe that you made a smart investment. In any case, reading the book will be especially useful for specialists in the following areas.
• Product managers and UX specialists in commercial companies manufacturing productsshould read this book to bridge the world of user experience and product performance to tactical plans and backlog elements. If you are having difficulty trying to move from the idea of a product to the individual details that your team should create, stories will help you. If you find it difficult to get other people to put themselves in the place of users, a story map will help you. If you can’t get together a good interaction design and practical product design together, this book will help you. And if you are trying to conduct an experiment in the style of a Lean startup, it will also be useful to you.
• Representatives of customers, business intelligence, as well as product managers in organizations involved in the field of information technologyshould read this book to build bridges between users, developers and other interested parties. If you spend a lot of effort so that all interested parties in your company finally come to some kind of agreement, story cards will help you. And if the developers find it difficult to try to draw a complete picture, the stories will be useful here.
• Agile and Lean process trainers should read this book if they want to help teams and individuals work more efficiently. In addition, just think about how misconceptions about the stories formed by the employees of your organization! Use the stories, simple exercises, and practices described in this book to help your teams grow.
• And finally, everyone else. When using Agile processes, we most often expect fruitful work with stories from people acting as business analysts or customer representatives, but the work will be truly effective if the basics are known to everyone. If people don’t understand the simplest things, you will often hear complaints that the stories are poorly written, or too long, or not detailed enough.
This book will help, but not in the way you expect. You, along with other readers, will learn that storytelling is not a way to write requirements better, but a path to more productive and organized discussions. This book will help you formulate what types of discussions are needed so that you have the right information at any time.
Chapters 1–4 will give you an overview of storytelling. If you already use them and have some experience, this part of the book will provide enough material to get down to business immediately.
Chapter 5 provides you with an excellent opportunity to practice the key concepts used to create the best story map. Try to do this in your office with a group of colleagues - as a result, each participant will gain useful experience. I promise: the cards you create will become better and better over time.
Chapters 6-12 talk a lot about user stories: how they work in reality, how to organize their use in Agile or Lean projects in the best way. In addition to story maps, there are several small examples that may be useful in daily development practice. Even if you are an Agile veteran, I promise you will learn something new for yourself about the stories. And if you're new to stories, you'll learn enough to hit the most arrogant know-it-all Agile in the office.
Chapters 13–15 reveal the details of the story life cycle. We will discuss specific practices that will help you use stories and story maps. Gradually, we will move from the opening prospects to creating a backlog filled with stories describing a viable product. You will learn how storytelling and other tricks can help you with every step of the way.
Chapters 16–18 will step by step devote you to the intricacies of storytelling tactics. You will learn to bring stories to the end, not to lose sight of them during the development process, to achieve their accurate execution, and also to draw experience from each story that you transformed into working software.
I have found that the last few chapters in most software development books are simply useless paper translations. Usually they can be skipped painlessly. Unfortunately, in my book I did not write anything like that and you have to read it in its entirety. I can only console you by the fact that in each chapter you will find some useful tricks and lessons that you can immediately put into practice.
Over 20 years of practical work, Jeff Patton was convinced that there is no one right way to design and develop software, but there are so many wrong ways. To help organizations improve their performance, Jeff has more than 15 years of experience working with a wide range of products, from an airplane parts online ordering system to electronic medical records. While many development processes focus on speed and productivity, Jeff balances these factors with products that provide business value and market success.
Jeff has decided to specialize in Agile approaches since working as an extreme programming team in 2000. In particular, he specializes in integrating effective user interaction design and product management into powerful engineering methods.
Jeff currently works as an independent consultant, Agile process trainer, product design process trainer and trainer. Many articles, essays, and presentations on various aspects of Agile product development can be found on agileproductdesign.com and in Crystal Clear by Alistair Coburn. Jeff is the founder and moderator of the Yahoo! by topic on usability at Agile, columnist at StickyMinds.comand IEEE Software, a certified Scrum trainer, and winner of the Agile Alliance's 2007 Gordon Pask Award for Contributing to Agile.
»More information on the book can be found on the publisher’s website
» Table of Contents
» Excerpt
For Savory Agents 25% off coupon - Patton
The author told how to avoid the maximum number of misunderstandings associated with the use of stories in the development of software using Agile and Lean methodologies.
If you use stories and suffer, this book is for you.
Quite a lot of organizations have already implemented Agile and Lean methodologies, therefore, it is quite possible that you have already managed to fall into one of the traps that arise due to a misunderstanding of the concept of stories. Here is some of them.
• Because stories let you concentrate on creating small pieces of software, it's easy to stop seeing the whole picture . The result is a typical Frankenstein product, for each user of which it is obvious that it consists of disparate, unrelated parts.
• When you work on a product of significant size, creating small particles one after another makes people wonder when you will finally finish and what will be the result . As if you are a builder.
• Since the main concept in the concept of stories is discussion, people often forget to keep notes . As a result, the subject of discussion and the agreements reached are forgotten.
• Since good stories assume acceptance criteria, we focus on defining these criteria. But this process and the description of the product being created are not the same thing. As a result, the team cannot finish the planned work in the scheduled time .
• Since good stories should be written from a user's perspective, but there are many aspects that the user simply does not see, team members say: “This product has no users, so user stories are not suitable here.”
If you have already fallen into one of these traps, I (the author) will try to clarify all the
misunderstandings that caused them. You will learn how to evaluate the full picture, productively discuss the goals and objectives of users and create good software.
Who else is this book for
For you, of course. Especially if you already bought it. I believe that you made a smart investment. In any case, reading the book will be especially useful for specialists in the following areas.
• Product managers and UX specialists in commercial companies manufacturing productsshould read this book to bridge the world of user experience and product performance to tactical plans and backlog elements. If you are having difficulty trying to move from the idea of a product to the individual details that your team should create, stories will help you. If you find it difficult to get other people to put themselves in the place of users, a story map will help you. If you can’t get together a good interaction design and practical product design together, this book will help you. And if you are trying to conduct an experiment in the style of a Lean startup, it will also be useful to you.
• Representatives of customers, business intelligence, as well as product managers in organizations involved in the field of information technologyshould read this book to build bridges between users, developers and other interested parties. If you spend a lot of effort so that all interested parties in your company finally come to some kind of agreement, story cards will help you. And if the developers find it difficult to try to draw a complete picture, the stories will be useful here.
• Agile and Lean process trainers should read this book if they want to help teams and individuals work more efficiently. In addition, just think about how misconceptions about the stories formed by the employees of your organization! Use the stories, simple exercises, and practices described in this book to help your teams grow.
• And finally, everyone else. When using Agile processes, we most often expect fruitful work with stories from people acting as business analysts or customer representatives, but the work will be truly effective if the basics are known to everyone. If people don’t understand the simplest things, you will often hear complaints that the stories are poorly written, or too long, or not detailed enough.
This book will help, but not in the way you expect. You, along with other readers, will learn that storytelling is not a way to write requirements better, but a path to more productive and organized discussions. This book will help you formulate what types of discussions are needed so that you have the right information at any time.
Mapping stories from a bird's eye view
Chapters 1–4 will give you an overview of storytelling. If you already use them and have some experience, this part of the book will provide enough material to get down to business immediately.
Chapter 5 provides you with an excellent opportunity to practice the key concepts used to create the best story map. Try to do this in your office with a group of colleagues - as a result, each participant will gain useful experience. I promise: the cards you create will become better and better over time.
Intuitive user stories
Chapters 6-12 talk a lot about user stories: how they work in reality, how to organize their use in Agile or Lean projects in the best way. In addition to story maps, there are several small examples that may be useful in daily development practice. Even if you are an Agile veteran, I promise you will learn something new for yourself about the stories. And if you're new to stories, you'll learn enough to hit the most arrogant know-it-all Agile in the office.
The best backlogs
Chapters 13–15 reveal the details of the story life cycle. We will discuss specific practices that will help you use stories and story maps. Gradually, we will move from the opening prospects to creating a backlog filled with stories describing a viable product. You will learn how storytelling and other tricks can help you with every step of the way.
Best development
Chapters 16–18 will step by step devote you to the intricacies of storytelling tactics. You will learn to bring stories to the end, not to lose sight of them during the development process, to achieve their accurate execution, and also to draw experience from each story that you transformed into working software.
I have found that the last few chapters in most software development books are simply useless paper translations. Usually they can be skipped painlessly. Unfortunately, in my book I did not write anything like that and you have to read it in its entirety. I can only console you by the fact that in each chapter you will find some useful tricks and lessons that you can immediately put into practice.
about the author
Over 20 years of practical work, Jeff Patton was convinced that there is no one right way to design and develop software, but there are so many wrong ways. To help organizations improve their performance, Jeff has more than 15 years of experience working with a wide range of products, from an airplane parts online ordering system to electronic medical records. While many development processes focus on speed and productivity, Jeff balances these factors with products that provide business value and market success.
Jeff has decided to specialize in Agile approaches since working as an extreme programming team in 2000. In particular, he specializes in integrating effective user interaction design and product management into powerful engineering methods.
Jeff currently works as an independent consultant, Agile process trainer, product design process trainer and trainer. Many articles, essays, and presentations on various aspects of Agile product development can be found on agileproductdesign.com and in Crystal Clear by Alistair Coburn. Jeff is the founder and moderator of the Yahoo! by topic on usability at Agile, columnist at StickyMinds.comand IEEE Software, a certified Scrum trainer, and winner of the Agile Alliance's 2007 Gordon Pask Award for Contributing to Agile.
»More information on the book can be found on the publisher’s website
» Table of Contents
» Excerpt
For Savory Agents 25% off coupon - Patton