A user story is not a detailed requirement. It is a reminder. A user story’s purpose is to remind us to have a detailed conversation … later. In some future Sprint Planning session, when we see the story, we will remember that we need to fully understand the story’s purpose and the expected outcome. We will have conversations with our customers and create tasks (and their estimations) to plan the technical work to accomplish the story’s purpose and detail acceptance tests (another kind of task) to specify the story’s expected outcome. I have to admit that in practice this process can be a little tricky for some domains. The user story is not always “OK to Go” the first time we remember to understand it. For example, the story “As a User I want to add a Patient to a service program so that standard protocols can be followed” brings up many questions. How does a service program enforce a standard protocol? What attributes of a Patient determine the need for a service program? What are the standard protocols? Do different service programs use the same standard protocols or different ones? This kind of information is not always “known” within a complex organization, especially if it is automated by a system targeted for retirement … and no one knows how the system actually works. Looks like somebody (a System Value Optimizer or a System Quality Optimizer) needs to do some research and (depending on the complexity) this research may take more than one iteration to complete. A good conversation would go something like this:
Product Owner: I want to schedule this story for Sprint 1
Team: Asks all the questions above of which the Product Owner does not have all the answers
Product Owner: OK. We’ll work on this one some more and have it ready for Sprint 2
Then while the development team is working on Sprint 1, other team members search out and gather all of the information required to answer the questions so the story can be planned with confidence for Sprint 2. Alternatively, the team could split the story and work on known parts during Sprint 1 and postpone the “unknown” parts until Sprint 2.
You can consider the strengths of the team to help make your decision. If a Strong System Value Optimizer and a Strong Application Architecture Optimizer are on the team, choose the second alternative due to the high probability of getting the information (system value) on time and getting it integrated into the next build (application architecture) on time. If both of these strengths are not present on the team, choose the first option and reevaluate the story for Sprint 2.