April 2009

We all know the importance of Done and the definition of done for user stories. delivered as an output from a sprint. Richard Kronfält has reminded me the input to the sprint must also be in a good shape:

    • A user story exists which points out the actor, describes the targeted feature and the purpose of it. The story should be formulated like this; As a I want to because . The first two are often easy to pinpoint but the purpose is often overlooked, because it feels obvious. But is it? The idea with writing down the purpose is to give the reader a good feel for the context of the feature what problem it solves. Not only what it is but also why. This way, the reader can form his own opinion on how to implement it. It gives the reader a deeper understanding for the story.
    • The formulation of the user story is general enough for the team to have the flexibility of delivering it in increments. Dont describe every detail. Describe roughly what you want but leave the rest for discussion.
    • The story is small enough to fit inside a sprint. Stories larger than that need to be broken down. Breaking down and reformulating stories have to be done before the sprint planning. Obviously, a story cannot be completed in a sprint if it is larger than a sprint. So care should be taken to ensure they are small enough.
    • Each story has its own unique priority in relation to every other story in the product backlog. This is to ensure that the team can work on the most important things first, and to force the product owner to make intelligent decisions about the order of stories.
    • The story has a description of how it can be tested (demoed). The description need to give the reader a good sense of what determines if the story is completed or not. It should be e.g. the acceptance test that is described here. It can be used as a description of how to demo the story too.
    • The story has been estimated (in story points). This should preferably be done by the whole or parts of the team, but at the very least it should be done by individuals with the same understanding of the system and the domain as the team who will eventually be working on it.

Scrum FTW!: Ready-ready: the Definition of Ready for User Stories going into sprint planning



The recipient’s of this year’s Shingo Prize have been announced. The Research and Professional Publication Prize category is a great reading list for new lean books:

Steven Spear – Chasing the Rabbit. A book on how to catch up with your lean competiors. HBR review here.

Mark Graban – Lean Hospitals. The book by the productive author of leanblog.org.

John Shook – Managing to Learn. Focuses on Toyota’s visual A3 management tool. * Professor Peter Hines; Dr. Pauline Found; Gary Griffiths; and Richard Harrison – Staying Lean: Thriving, Not Just Surviving.

Jeffrey K. Liker, Michael Hoseus and the Center for Quality People and Organizations – Toyota Culture. Great author, new book. What’s not to like?

Durward K. Sobek II and Art Smalley – Understanding A3 Thinking. Another winning book on Toyota’s A3 tool from Productivity Press.

New Lean Reading List: Shingo Prize Winners Announced – Ative at Work