Are You “Ready” to Cook Up Some User Stories?

“Ready” is a Scrum concept that applies to making sure that the Team has enough information about user stories to be able to implement them in an upcoming sprint.

Roman Pilcher says that a “ready” story should be clear, feasible, and testable. I’m fond of analogies, and I think the concept of ready also applies to cooking. Suppose you are getting “ready” to cook a new recipe for dinner – what do you need to do? Basically, you need to read the recipe, and assemble the ingredients.

Ingredients

What ingredients might you need to make your stories “ready” to cook up in the next sprint? Some ingredients might include:

– Domain knowledge: Do you need to get information from the users or other stakeholders before the story can be implemented?

– Narrative: Is this story part of a larger narrative? Most stories are, and narratives can provide context for an individual story.

– Acceptance criteria – How will you know when the story is done? How should the story behave? Acceptance criteria provide the basis for testing the story.

– User interface mockups – A picture is worth a thousand words, so creating a quick mock-up allows the Product Owner and the Development Team to have a clearer picture of what the interface should look like, and usually also helps define clear acceptance criteria.

– Data definitions – Is there data associated with the story? If there is, what are the data elements, and what are their attributes? Any default values? Should input data be validated? Many agile teams use a data dictionary to capture this type of information, which is wise since most data elements are used in multiple stories, and the data dictionary makes it easy to capture and maintain that information in just one place.

– Qualities (AKA non-functional requirements) –  What qualities does the story need to have? Are their security or privacy concerns for data that is being captured? What about performance? Usability?

Suppose we were about to “cook up” this story:

As a sailboat renter, I can see a list of boats in a selected location so that I can see what boats are available there.

What ingredients do we need to have in order to be ready to cook?

– User interface details: What should the list look like? What order should it be in? (Domain knowledge might help with this question – should catamarans and mono-hulls be listed separately?) Should the list be sortable? If so, how should the user be able to sort it? You could capture some of this information in a simple mock-up, and some of it in acceptance criteria.

– Narrative: This story is part of narrative in which a prospective renter is searching for a boat to rent. When they select a boat, what should happen next? That will most likely be a different user story, since this story is about displaying the list of boats, not about selecting one. You often discover additional stories during this process. But knowing that the user will need to be able to select a boat to get more information about it also helps the team see the context in which the story will fit.

– Data definitions: What should each boat description contain? Should it have a snapshot of the boat? What other information should be displayed? When the user hovers over a boat, should more information be displayed? Do we already have a data dictionary description for a boat and its attributes? Do we need to modify it for this story?

– Qualities: Are there any qualities that apply to this story? From a usability standpoint, what if the list of boats is really long? What kind of scrolling should we provide? How should we indicate that there are more boats in the list?

If you are more familiar with the waterfall than the agile approach, this probably sounds a lot like detailed requirements analysis. There is a big difference though – in the agile approach you do this type of analysis on a just-in-time basis, in the context of what you have already learned and what you have already developed, rather than trying to figure it all out up front.

Spending some time defining what ‘ready” means for your team – The Definition of Ready – will help your team know what ingredients you need in order to cook up a great product increment in the next sprint.