LTYM - Sorting Stories

Letters to a Young Manager

Sorting Stories, #61
LTYM > Project Management

Dear Sophie,

***

As we leaned from the iron triangle model, the factor that most often goes to the project team is scope. [1] The way you can manage this is through creating and sorting "story cards". This is a project method introduced by Extreme Programming in 1999 and is quite useful and easy for business users to understand. [2]

As Kent Beck wrote, a story card is "customer-visible functionality," a basic functional element that both the customer and the developers understand [3]. As new features are identified and new nuances of prior features clarified, each is written on an index card. On a regular basis, this "deck of cards" is sorted with the customer so the most important features are in top.

Managing scope, then is a matter of constantly being clear about which features are in the phase and which move to the next phase. Scope is a matter of "cutting the deck" into a doable stack.

We had this challenge at Save the Children with the Sponsorship Assignment project. The more we discussed needs and features, the longer this list became. So the project manager introduced the story-card approach. Any good idea was fair game, and the project team of users and developers was good at generating ideas and exceptions. Most knowledge organization are. But as the deck grew, it was reshuffled (sorted) and cut into the phase one pile and the phase two pile. This kept phase one on track, while not losing any of the good ideas that may be deferred to phase two or three. [4]

This basic method of managing scope was refined throughout the last decade as agile methodologies gained in popularity[5]. But the basic concept is still the same.

***

Sincerely,
Ed

________________________

[1] See "Giving the Third to the Architect," Story #44
[2] See Martin Fowler's delightful explanation of story cards and their origin in "UserStory". For an interest comparison of User Stories and Use Cases see his article "What is the difference between a UseCase and XP's UserStory?"
[3] Kent Beck, Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series), Addison-Wesley; (November 26, 2004), p. 44.
[4] See "Saying No Without Saying No," Story #36
[5] See Mike Cohn's, User Stories Applied: For Agile Software Development, Addison-Wesley Professional; 1 edition (March 11, 2004) and the more recent book by Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product, O'Reilly Media; 1 edition (September 25, 2014)

Takeaways:

Sorting stories about features keeps priorities visible

Discussion Questions:

1) Would you automate the story card method? Why or why not?
2) What if sort cards are not detailed enough; what would you do next?
3) How would you decide where to cut the deck into phase one and two?
4) If the business user demands a feature stay in phase one and is unwilling to de-prioritize something else, what is your approach? (Hint: go back to the iron triangle).

For Further Reading:

Kent Beck, Extreme Programming Explained, Addison-Wesley Professional; US edition (October 5, 1999); and Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series), Addison-Wesley; (November 26, 2004)
Mike Cohn, User Stories Applied: For Agile Software Development, Addison-Wesley Professional; 1 edition (March 11, 2004)
Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product, O'Reilly Media; 1 edition (September 25, 2014)