User Stories Applied: For Agile Software Development.
March 2004, 268 pp., Softcover
Mike Cohn’s book User Stories Applied: For Agile Software Development describes what user stories are, what the work with them entails and how they can be used as part of the Scrum agile framework.
What Martin Fowler called “the standard book on writing user stories” is without doubt one of the important reads of the agile movement.
Cohn structures his book into five parts. He starts with the basics concerning user stories: gathering, writing and testing them. In the second part the author continues with the topics of estimating and planning user stories. The third part titled Frequently Discussed Topics is a more elaborate form of a FAQ-section (frequently asked questions) concerning stories.
Each chapter of these three parts finishes with a very comprehensive summary and a set of questions for self-testing one’s understanding. Some of the chapters also summarize the responsibilities of the developers and customers which follow from the chapters‘ content. Part four exemplifies the procedures presented throughout the book by means of a hypothetical project.
The appendices contain a short but very encompassing overview of the techniques and values of extreme programming, the methodology which first used user stories and answers to the self-test questions.
Part 1 – Getting Started
The first chapter of the book starts with a very short summary of the cornerstones of software engineering projects. The author considers project requirements as a form of communication. A power imbalance in this process is to be seen as bad for the project. Software projects cannot be perfectly predicted and that is why an appropriate process is necessary. User stories are an important part thereof. User stories “describe functionality that will be valuable to either a user or purchaser of a system or software” (p. 4) and are made of a description which serves as a reminder, the conversations around the story and the acceptance tests which validate the implementation. User stories can have varying sizes. Very large ones are called epics.
Cohn uses throughout the book a fictitious project called
BigMoneyJobs – a job and recruitment engine – for exemplifying the theoretical aspects. The remaining of the chapter tackles various details concerning user stories: their richness of detail, points in time when to be written, their testing, planning and prioritization.
Chapters 2 and 7 particularize the properties of user stories respectively the quality criteria they should conform to. According to Cohn, stories must be:
- valuable to purchasers or users
- and testable
Cohn suggests Bill Wakes‘ acronym INVEST for condensing the criteria.
Some of the quality criteria include writing stories for only one user, keeping the UI out as long as possible, writing in active voice and several more.
Chapter 3 deals with user role modelling. The author sees this aspect as very important and considers taking only one type of user into account when writing stories a fallacy. He also introduces a simple process for user role identification consisting of four steps (p. 33):
- brainstorming an initial set of user roles, a task to be fulfilled by the customers together with the developers,
- organizing the set,
- consolidating the identified roles
- and performing a final refinement step.
The techniques of creating personas and considering extreme characters are shortly presented as ancillary helpful procedures.
The author continues with presenting techniques for gathering stories and argues against using such terms as requirements “elicitation” or requirements “capture” despite their wide usage. He considers them inappropriate preferring the term “trawling” introduced by Suzanne and James Robertson in 1999. Cohn further describes four techniques with their opportunities and drawbacks: user interviews, questionnaires, observation and story-writing workshops. Finally, he summarizes that using a combination of all of them elicits the best results.
Since working directly with users is not always possible (which would be the ideal though), Cohn identifies possible user representatives – user proxies – and discusses their fitness for the role and possible implications on the project (chapter 5). These possible proxies are:
- the user’s manager
- a development manager
- domain experts
- marketing people
- former users
- trainers and support people
- business or systems analysts
- the software developer himself, who is considered in most cases as the most inappropriate proxy.
Before closing the first part with the list of quality criteria for user stories (chapter 7) the author discusses the topic of acceptance tests which is an inherent part of the stories. Cohn stresses the importance of writing acceptance tests before coding and underlines that the customers are responsible for specifying the acceptance tests with possible support from the development team. Ward Cunninham’s Framework for Integrated Test (FIT) and the FitNesse-Framework which builds upon FIT are presented as useful tools for acceptance testing.
Part 2 – Estimating and Planning
Part two of the book comprising the chapters 8 to 11 deals with estimating user stories, prioritizing them as part of iterations and releases and measuring the velocity.
According to the author the prerequisites for the estimation technique employed should be:
- independent of the story size
- imprecision-tolerant and
Story points – a freely definable measure for time, effort or complexity – are considered to fulfill all the requirements. Cohn favors equaling one story point to an “ideal day of work” i.e. a day without any interruptions whatsoever and full concentration on the tasks at hand. Since the team owns the estimates, it’s also them who have to do the estimating and not individual programmers.
Chapter 9 draws on planning releases. For prioritizing Cohn suggests the MoSCoW rules borrowed from the agile process Dynamic Systems Development Method (DSDM). MoSCoW is an acronym for Must have, Should have, Could have and Won’t have this time.
Stories themselves can be prioritized along various dimensions. It is important though to consider also prioritizing infrastructural needs. The velocity which is “the amount of work that gets done in an iteration” (p. 103) is an important metric for agile processes.
The chapter finishes with an important warning indicating the difficulty of precision when building software:
Be careful not to put too much faith in the release plan. The techniques described in this chapter will help you estimate the approximate duration of a project and allow you to make statements like ‘The product will be ready for release in approximately 5-7 iterations.’ They don’t give you enough precision, however, to say things like ‘We’ll be done on June 3.’Mike Cohn – User Stories Applied, p. 106
Release plans are subdivided into iterations which can lead to a segmentation of stories into smaller tasks for which developers accept the responsibility. Tracking the velocity is important, cumulating story points and hours into burndown charts on an iteration or daily basis are helpful tools for prediction. Finally, the author highlights the importance of making the progress visible.
Part 3 – Frequently Discussed Topics
The third part of the book contains much in the tradition of FAQ lists, answers to some very specific questions which might arise while reading the book. It starts by comparing user stories to other forms of requirements like
- IEEE 830 requirements,
- use cases and
and concludes that user stories are different from these while being most similar to use cases and most different from IEEE 830 requirements.
In the subsequent chapter the author summarizes the reasons why user stories are optimal as a requirements technique. He restates some of his arguments written elsewhere in the book and lists cases when user stories might be sub-optimal. Among the arguments brought in favor of user stories are their general comprehensibility, their encouragement of participatory design and their emphasis on verbal communication. Stories are no good fit for large projects with many features since they are rather difficult to track.
Chapter 14 creates a comprehensible list of story smells and how they can be avoided or at least dealt with:
- Insufficient size
- Addition of UI details in an early phase
- Excessive forethought
- Excessive story splitting
- Prioritization problems
- Customer refuses writing and/or prioritizing stories.
The subsequent chapter Using Stories with Scrum advocates the usage of user stories as a requirement gathering technique in the Scrum agile process. Based on Schwaber’s and Beedle’s Agile Development with Scrum Cohn summarizes the roles, meetings and processes of Scrum describing how user stories would fit. The chapter concludes with an example from the author’s working experience where such a setting lead to very positive results.
Part 4 – An Example
The fourth and last part (ignoring the appendices) describes in a very comprehensive way how the tenets of the previous chapters can be applied. The processes of customer identification, role modeling, definition of personas, identification and estimation of stories, release and iteration planning and definition of acceptance tests are demonstrated on a fictional project of the fictional South Coast Nautical Supplies company.
What Martin Fowler called “the standard book on writing user stories” is without doubt one of the important reads of the agile movement. Being both comprehensive and comprehensible the book is one of the important lectures for product owners and scrum masters and to a much lesser degree for developers.
Its structure containing very good summaries at the end of each chapter and self-test questions encouraging exercise is clearly designed with the idea of a reference book in mind. Being familiarized with the topic of user stories from hands-on experience you probably won’t get much out of the book though, but as an entry point into the user story topic, the book is very good.
Mike Cohn is one of the most important proponents of the Scrum software development method. He worked at several companies before he created his own consultancy company Mountain Goat Software in 1989. He wrote over ten books on the topics of agile development in general and Scrum in particular.
Folgende Bücher könnten Sie ebenfalls interessieren: