Source (tentative): Cohn, Mike. Agile Estimating and Planning. [Anyone know the original source? ]
The original XP take on what made a good story was that it had to have business value, it had to be estimable, and it had to be testable. That might have made for a simpler and also appropriate acronym, VET. But the three newer elements (I, N, S) add considerable value in helping you shape a candidate story into a real story that can be accepted in an iteration.
- Independent - Any story could be the next one done; the customer should have the final say. As stories complete, some may become cheaper and others more expensive. Tim recommends estimating all stories as if they were first, and re-evaluating estimates before iteration planning game.
- Negotiable - A story is not a contract! It is a "promise for communication," as we used to say. It shouldn't be flush with every last detail.
- Valuable to the customer - Don't create technical stories! A primary goal of using stories is to demonstrate to the customer that we can deliver business value incrementally, so that the customer can help steer us and provide us with feedback. I'll repeat, because it's very important: Don't create technical stories!
- Estimable - A story might be impossible to estimate if it's too big, or if we have no idea what's involved, in which case we probably need to go off and to a bit more research before we present this story.
- Small - Some sources replace "small" with "sized appropriately." Size will vary on your shop, but obviously, a story can't represent more than a single iteration's worth of work. A better rule of thumb would be that no story would represent more than half the iteration. To me, an ideal size would mean that your team could crank out a story every day. It is possible to make stories too small, but very rare, so the general rule is "smaller."
- Testable - If you can't verify it in some manner, how do you know it's done?
I've always found this to be hugely useful. Always re-writing this one! :-)
ReplyDeleteAlso, as for Small...I am one of the "Sized appropriately" people. Reason: "appropriately", based on purpose. More specifically, for example, I think its okay (preferable even) for stories that represent "way down the road" work, or a "just barely thought"/"might do" idea to be "bigger", whereas a story whose purpose is to represent iteration deliverables should, as you note, be much smaller. Or even something akin to Jeff Patton's ideas of "User activities and tasks", where activities are bigger stories, and tasks are the smaller stories that we actually implement at an iteration level.
Anyway, good stuff!
MB
BTW, I think INVEST comes originally from Bill Wake.
ReplyDeleteThe original XP take on what made a good story was that it had to have business value, it had to be estimable, and it had to be testable. That might have made for a simpler and also appropriate acronym, VET. Ascenergy
ReplyDeleteI remember struggling with some of the things in INVEST, and like the shorter VET. Small and negotiable always seemed obvious (or a bit vague) to us in the XP days. Independent is a good addition, though. VITE? VIET?
ReplyDelete