"INVEST" in Good Stories

In Scurm/XP, we think of requirements of coming in the form of user stories. It would be easy to mistake the story card for the "whole story," but stories in Scrum/XP have three components: Cards (their physical medium), Conversation (the discussion surrounding them), and Confirmation (tests that verify them).

A pidgin language is a simplified language, usually used for trade, that allows people who can't communicate in their native language to nonetheless work together. User stories act like this. We don't expect customers or users to view the system the same way that programmers do; stories act as a pidgin language where both sides can agree enough to work together effectively.

But what are characteristics of a good story? The acronym "INVEST" can remind you that good stories are:

• I – Independent
• N – Negotiable
• V – Valuable
• E – Estimable
• S – Small
• T – Testable

Independent

Stories are easiest to work with if they are independent. That is, we'd like them to not overlap in concept, and we'd like to be able to schedule and implement them in any order.  We can't always achieve this; once in a while we may say things like "3 points for the first report, then 1 point for each of the others."

Negotiable… and Negotiated

A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don't need these to prioritize or schedule stories.

Valuable

A story needs to be valuable. We don't care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important.
This is especially an issue when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we're serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it "right"); but a full database layer (for example) has little value to the customer if there's no presentation layer.

Estimable

A good story can be estimated. We don't need an exact estimate, but just enough to help the customer rank and schedule the story's implementation. Being estimable is partly a function of being negotiated, as it's hard to estimate a story we don't understand. It is also a function of size: bigger stories are harder to estimate. Finally, it's a function of the team: what's easy to estimate will vary depending on the team's experience. (Sometimes a team may have to split a story into a (time-boxed) "spike" that will give the team enough information to make a decent estimate, and the rest of the story that will actually implement the desired feature.)

Small

Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what's in the story's scope. Saying, "it would take me more than a month" often implicitly adds, "as I don't understand what-all it would entail." Smaller stories tend to get more accurate estimates.
Story descriptions can be small too (and putting them on an index card helps make that happen). Alistair Cockburn described the cards as tokens promising a future conversation. Remember, the details can be elaborated through conversations with the customer.

Testable

A good story is testable. Writing a story card carries an implicit promise: "I understand what I want well enough that I could write a test for it." Several teams have reported that by requiring customer tests before implementing a story, the team is more productive. "Testability" has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met. If a customer doesn't know how to test something, this may indicate that the story isn't clear enough, or that it doesn't reflect something valuable to them, or that the customer just needs help in testing.
A team can treat non-functional requirements (such as performance and usability) as things that need to be tested. Figure out how to operationalize these tests will help the team learn the true needs.

[Ken Wake developed the INVEST acronym, and wrote this article in April and August, 2003.]

Orwell's Question

In Dr. Gee's book, Anti-Education, he begins by raising a question that George Orwell did in his book, 1984, asking why humans so often believe things are manifestly false.  Although Orwell was thinking of totalitarian regimes,

the phenomenon flourishes in free societies as well.  It is a human trait easily exploited by politicians, charlatans, and the media... We are extremely good at believing what we want and need to believe, even in the face of counter-evidence (Gee, p. 1).

Gee says we live in an era of anti-education, where he thinks schools and colleges don't "prepare people to participate in a true democracy where their votes are based on considered arguments backed by evidence," and assuming you are given the chance to vote.

In preparation for the exam question on this topic, ask yourself how you come to know what you know about the world around you.  Are you easily exploited by politicians, celebrities, and the media?  "Disrespecting the world - by disrespecting facts, for example - is what leads to stupidity."  Here are two examples that explain this point further.  One is a 4-min podcast; the other is a 5-min video. They both describe what happens when the media presents "the facts" as a debate.

1. "On the Anti-Vax Non-Troversy" , Feb. 6, 2015 by Bob Garfield (podcast), On The Media 
2. Last Week Tonight with John Oliver on Climate Change, May 11, 2014 (video, explicit).

After you listen to and watch the media, you can comment below with your thoughts on the issue.

Group Blog Changes & Requests

I created a some instructions for how to make group blog changes in a Screencast (mp4) that you can view as a visual reminder of the steps to take for these changes.   After you create your blog, make these 4 changes (all of which are shown below):

1. Make sure you have a list of contributors on your site (some do; some don't) - the list should include all members who are authors/admins of your blog.
2. Allow all members to get emails of the posts you make to the site.
3. Change your blog from private to public. The reason is that I want to create a blog roll on the class-specific website so that others can view the videos you are creating.  (A blog roll shows the most recent post on the blog.)
4. Change me from author to admin to your group blogs.  I won't change anything without your permission, but if there are questions about the blog or problems you may have with it, it makes it easier for me to respond.  

All of these issues, including the PREVIEW button before posting are shown in the short screencast below.  (If you already know how to do this, the screencast is optional.)