Grooming user stories and decomposing features is not always easy. The demands to fill a sprint backlog for an agile feature team in a large enterprise are already immense, and tight project deadlines only compound the issue. Outside stakeholders may not understand the effort it takes to prepare a single user story and define acceptance criteria. Try settling on a single “definition of ready” with your scrum team to help alleviate the stress of grooming.
Definition of done is generally well understood within development circles. For a user story to be considered done, a certain set of predefined criteria must be met for the story during a single sprint. This definition can include various levels of testing, deployment instructions, and other dev activities. Consider setting up a similar checklist for user story grooming.
The exact definition of ready, just like of done, will vary across organizations and teams. The definition of ready will let you easily communicate the status of stories being analyzed, both to team members and managers and other outside stakeholders. When a project manager or dev lead asks for the status of a given story, you can walk through the list and determine when the story will be ready and raise any impediments to completing the analysis.
To develop a comprehensive definition of ready, spend a grooming cycle cataloging all analysis activities that go into a single user story. Please consider pulling individual items into your checklist from the following areas:
Obviously, a user story needs to be written in order to be complete. Does each story clearly articulate a user, a desired functionality, and a business purpose for development. Furthermore, does the story honor the INVEST criteria for good requirements? Has the team sized the story and is it prioritized within the sprint?
Each team has a different level of technical detail required to begin development. Mature teams may not need much more than the story and acceptance criteria to begin development. New teams may require explicit technical detail, deployment instructions, interface mapping, and more.
Requirements Tool Work
Are the requirements entered into the requirements tool? Are the requirements traced to other requirements objects, like features, epics, and predecessor stories? Consider linking each story to a business objective to ensure proper prioritization
Where does this story fit within the sequence for the feature or epic? Does this story have any external dependency? Are any interlocking teams dependent on this user story to begin development on other functionality? Should this story fit into a sequence within the sprint?
Acceptance criteria must be reviewed with the testing team prior to development beginning. Are the criteria sufficient? Do they enumerate positive and negative scenarios for the user story?