Summary

My first impression of the book is how small the chapters are.  The chapters are very focused on small topics.  Also, I find the Mike Cohn’s writing style to be very casual (which is good).  Too many people talk as if they are the definitive answer and must impress upon you why their opinion is right.  Mike Cohn starts off with an attitude that says, hey this worked really well for me in what I did.  I saw others doing something different and they never did as well as I did.  There is no theory here, only practice from the trenches.  Much of the material is very introductory.  The chapters are small and self-contained, but at least in Part I, the topics are written at the beginner level with little emphasis on more detailed or complex ideas.  It was neat to read about how stories are useful in scrum. Today I don’t think anyone attempts scrum without stories, though done a bit differently than the XP way.  Interesting that this book was written (copyrighted) in 2004, only ten years ago.  I love how through the book he stresses “do what makes sense”, probably because this book is based on practice, not theory.  The book includes a rather lengthy example at the end, which is not common.  Could it be they needed to get the book longer and this was the best way?   It is effective, but I don’t think necessary, especially with today’s use of agile, stories are not so uncommon.

Top 3 Things I learned

1. Constraint cards, like user stories, show a constraint.  Can be automated and tested.
2. Use big visible charts, use the plotter for your burn-down chart.
3. The story smells was a very useful and practical chapter.

---

NOTES: Chapter 1: An Overview

SUMMARY: An introduction to user stories , how they are created and how they are used.

CONCEPT: User Story: Functionality that is valuable to a user.  Length is 1/2 a day to 2 weeks by a pair of programmers.  Expectations best captured by acceptance tests.

• Card — written description to id the card
• Conversation — about detail
• Confirmation — tests about detail to know I am done

CONCEPT: Customer Team: Beyond a product owner, group that ensures software meets needs.  Includes product owner, business analysts, testers

CONCEPT: Story Writing Workshop: Brainstorm the initial stories, write as many as possible

CONCEPT: Two different types of planning

• Release Planning: Focus is timeline and a set of functionality
• Iteration Planning: Which stories go in an iteration

CONCEPT: Why user stories

• Emphasize verbal communication
• Work for developer, business, and tester
• Right sized
• Iterative development
• Defer detail until known

---

NOTES: Chapter 2: Writing Stories

SUMMARY: Introduces the concept of INVEST and walks down each of the letters in the acronym: Independent, Negotiable, Valuable, Estimable, Sized Small, Testable

CONCEPT: Independent

• To make less dependent: make it generic: Card A, Card B, Card C for credit card payments
• To make less dependent: make it generic putting the estimate on the first one high, and the others less: Card A, then Card B & C, card independent
• If you cannot separate them, make to estimates on each card, X if done first, Y if done after another

CONCEPT: Negotiable: Stories are not written requirements.  Tough when work is contracted out in the government.  Stories are for conversations, details are for test.

CONCEPT: Valuable.  Try to write stories in a lingo that shows value to customer. (Personally I don’t think that is always worth the effort)

CONCEPT: Estimateable. When you can’t estimate, the answer is always a spike, just enough to know to estimate:

• Lack Business knowledge
• Lack Technical knowledge
• Too Big

CONCEPT: Sized small. Techniques to right-size

• Too Complex: Spike so you know more
• Compound: Split along CRUD
• Too Small: Clip together until at least a half day

CONCEPT: testable: ask how you are going to automate

---

NOTES: Chapter 3: User Role Modeling

SUMMARY: Introduces user role modeling.  Describes steps to take: brainstorm, group, consolidate, refine roles, remove unimportant roles to the system.  Talks about the attributes of a role.  Introduces two bonus round topics to be used only if applicable: personas and extreme characters.

CONCEPT: User Role Development

1. Brainstorm
2. Group
3. Consolidate/Condense
4. Refine Roles
5. Remove unimportant
6. [Optional] Personas
7. [Optional] Extreme Characters

CONCEPT: Attributes for a role

• Frequency user will use software
• Level of Expertise
• Proficiency with the software application
• General level of proficiency
• General goals with the software

---

NOTES: Chapter 4: Gathering Stories

SUMMARY: Some introductory material on why we don’t elicit or capture requirements.  We trawl.  Explains why trawling is a good metaphor.  Then drops into how to get good stories and the pros and cons of four techniques.

CONCEPT: Why requirements is like trawling.

• Different size nets give you a different amount of requirements and different sizes
• Requirements mature and may die or change in importance
• You will never catch all of them in one area
• Skills plays a role

CONCEPT: 4 techniques

• User Interviews
  • default approach
• Questionaires
  • Beware of closed end questions
  • Good if you already have stories
  • good for a large user population
  • not a primary means to gather user stories
• Observation
  • If you can observe, do it
• Story writing workshops
  • write as many as you can, docus on quantity
  • most effective way
  • very high level

---

NOTES: Chapter 5: Working with User Proxies

SUMMARY: Introduces different types of user proxies.  The back part of the chapter talks about how to work with user proxies.

CONCEPT: User Proxies

• User’s Manager
  • Bait and Switch
• Development Manager
  • Some conflicting goals
• Salespersons
  • Emphasis on lost sales
  • Great conduit to users
• Domain Experts
  • build a domain model (good)
  • identifying business rules (good)
  • workflow and usage issues (bad)
• Marketing Group
  • Understand markets not users
• Former users
  • good if experience is recent
• Customers
  • make buying decisions not users of the software
• Trainers and Technical support
  • skewed to make easier for their area
• Business or Systems analyst
  • good user proxies
  • like to think rather than research (bad)

CONCEPT: User Task Force

• Any number of real users
• sounding board
• proxy makes final decisions

---

NOTES: Chapter 6: Acceptance Testing User Stories

SUMMARY: Makes a brief case for specifying the test before coding, who writes them, (customer) and how they need to be automated.  No concepts presented here, though there is a recommendation for FIT and FITnesse.

---

NOTES: Chapter 7: Guidelines for Good Stories

SUMMARY: Given this book is about user stories, it makes sense that there are many good ideas here and there are some foundational concepts.  There is not much detail behind the ideas, and it is all practice not theory.  I like the constraint card.

CONCEPT: Guidelines

• Start with goal stories
• Slice the cake
• Write closed stories
• Put constraints on cards
• Size the story to the horizon
• Keep the UI out as long as possible
• Some things aren’t stories
• Include User Roles in the story
• Write for one user
• Write in active voice
• Customer writes
• Don’t number story cards
• Don’t forget the purpose

CONCEPT: Constraint Cards.  Not user stories, but a story card labeled as constraint to be a reminder.  Can be automated, tested, and accepted.

---

NOTES: Chapter 8: Estimating User Stories

SUMMARY: Introduces story points, triangulation (place similar story point values together to better understand if estimates are correct), planning poker, and discusses central limit theorem and velocity.

---

NOTES: Chapter 9: Planning a Release

SUMMARY: A very superficial approach to release planning.  Seem like an approach that would only work for very small teams.

CONCEPT: Main Points

• Things to ask at the beginning
  • When do we want the release
  • What is the priority of each story
• What goes in (DSDM approach) : Note I find most organizations are not mature enough to use this approach
  • Must have
  • Should have
  • Could have
  • Won’t have this time
• Prioritization
  • Can be risk based (Cohn does not prefer this because things may change and make this OBE)
  • Can be impact based (Makes people happiest)
  • Desireability to a broad user base
  • Desirability to a small number of important users
  • Cohesiveness of story in relation to other stories
• Mixed Priorities: If you have an issue prioritizing, then split them
• Risky stories, Cohn perfers the juicy bits first.
• Prioritizing infrastructural needs: Cohn tends to shy away from these, almost like he hopes they go away
• Selecting an interation length
• From story points to expected duration
• How to determine the initial velocity
  • Use history
  • Run an intial iteration and then you know
  • Take a guess

---

NOTES: Chapter 10: Planning an Iteration

SUMMARY: Talks about iteration planning with the decomposition of stories into tasks.  Follows 4 steps (listed below).

CONCEPT: Iteration Planning

1. Customer discusses the story
2. Developers ID tasks
3. 1 developer takes the task
4. At the end review the workload of each developer and adjust

NOTES: 

• At the beginning it is good to revisit and adjust the priorities
• Tasks are short mini-design activities
• Tasks are done in ideal days

---

NOTES: Chapter 11: Measuring and Monitoring Velocity

SUMMARY: Talks about how to make a burndown chart

---

NOTES: Chapter 12: What Stories are Not

SUMMARY: Discusses three things that user stories are not.  #1. IEEE 830 System Requirements Specification.  #2.  Use Cases.  #3 User Scenarios.  The issue with #1 is that you don’t get the feedback from the users.  The issue with #2 is that it is hard to get the User Interface interactions correct. The issue with #3 is that they are too large.

---

NOTES: Chapter 13: Why User Stories?

SUMMARY: Walks through several reasons why stories are good and ends with why they are not always good.

CONCEPT: Why stories are good

• Stress verbal communication
• Comprehensible by everyone
• Right size for planning
• Work for iterative development
• Defer detail
• Opportunistic design
• Participatory design
• Build up tacit knowledge

CONCEPT: Weaknesses of stories

• Difficult to understand relationships
• Additional documentation is required
• May not scale well

---

NOTES: Chapter 14: A Catalog of Story Smells.

SUMMARY: A wonderful discussion on story smells.

CONCEPT: Smells / Symptoms / Ideas

• Stories are too small / Frequent estimate revisions / make larger
• Interdependent Stories / Difficult planning because of dependency / Split complex per notes earlier
• Goldplating / Features not planned / Don’t do
• Too many Details / Too much time spent on details / use a smaller card
• Including UI details too early / stories written early include UI / Wait
• Thinking too far ahead / Hard to fit stories in / avoid large up front design
• Splitting too many stories / Frequent splitting / groom backlog
• Customer has trouble prioritizing / can’t prioritize / use smaller stories
• Customer wont write or prioritize / blame / remove blame

---

NOTES: Chapter 15: Using Stories with Scrum

SUMMARY: Talks about how well stories align with scrum.  Translates scrum terms for XP’ers.

CONCEPTS: Scrum basics

• Scrum is incremental (done in pieces) and iterative (successive refinements)
• Uses terms sprints (30 days of work), product backlog (all work to do), sprint backlog (current iteration), daily scrum
• Team is 4-7 developers, works is owned collectively, self-organizing.
• ScrumMaster and Product Owner drive things, though by serving a team rather than directing them
• Sprint Planning meeting, where you set a spring goal
• Sprint Review, you look at a potentially shippable increment

CONCEPT: The Main Rules of Scrum

• Sprints begin with Spring Planning
• Each sprint must deliver working and fully tested code that demonstrates something of value to the end-customer
• The product owner prioritizes the product backlog
• Team collectively selects the amount of work brought into the sprint
• Once a sprint begins, only the team can add to the sprint backlog
• Product backlog can be added to or reprioritized at any time
• Daily scrum.
• Only active participants may speak in the scrum
• Result of a sprint demonstrated at the sprint review
• Only working software
• No more than two hours may be spent preparing for the spring review

---

NOTES: Chapter 16: Additional Topics

SUMMARY: Covers 1. non-functional requirements (with a nice list of categories) but little in the way of how to address them other than constraint cards.  2. paper or electronic.  He shares his opinion that either is okay if done for a reason.  3. UI Stories, his advice is to hold off and delay writing things (I agree, you can’t wait long, but it is like a screen pass the longer you can wait the more blocking you will have and the bigger your gains). and 4. stories for bugs (do it, may need to consolidate)

CONCEPT: Non-functional requirements

• performance
• accuracy
• portability
• reusability
• maintainability
• interoperability
• availability
• usability
• security
• capacity

CONCEPT: Agile usage-centered design

1. User role modeling
2. trawl for high-level stories
3. prioritize
4. refine high and medium priority
5. organize into groups
6. create a paper prototype
7. refine the prototype
8. start programming

---

---

SECTION NOTE: The following chapters 17 through 21 reflect a scenario/example.  I will only hightlight the steps used, there are no new concepts introduced

---

---

NOTES: Chapter 17: The User Roles

1. Listed out the project
2. Identified the customer
3. Initial roles
4. Consolidated and Narrowed
5. Role Modeling
6. Personas

---

NOTES: Chapter 18: The Stories

Wrote stories (at a very high level)

---

NOTES: Chapter 19: Estimating the Stories

Estimated the stories

---

NOTES: Chapter 20: The Release Plan

Wrote a release plan

---

NOTES: Chapter 21: The Acceptance Tests

Wrote an acceptance test

---

NOTES: Appendix A: An Overview of Extreme Programming

CONCEPT: XP Practices

• Small releases
• the planning game
• refactoring
• testing
• pair programming
• sustainable pace
• collective code ownership
• coding standard
• simple design
• metaphor
• continuous integration
• on-site customer

CONCEPT: XP values

• communication
• simplicity
• feedback
• courage

CONCEPT: XP key principles

• rapid feedback
• assume simplicity
• incremental change
• embrace change
• quality work

NOTES: Appendix B: Answers to Questions