User Stories: a collaborative approach to requirements
User Stories are proposals or experiments. Experiments make hypotheses about how the world is. User stories are based on assumptions about business value, and those assumptions might turn out to be right or wrong. Stories shouldn’t be small because they need to fit into an iteration, but the world shouldn’t end because a story turns out wrong. The assumptions made by stakeholders and the delivery team must be confirmed. Suppose the team is incapable of dependency or needs to provide the expected functionality. In that case, the team is not the right for such functionality. It needs new members with the required knowledge.
User Stories are not complete requirements but tokens of conversations. It’s more of a *question* than an *answer*. User stories thus represent a contract between stakeholders and the delivery team. Creating a user story promises that the business stakeholders and the delivery team will meet at some point to discuss the details.
Instead of changing deadlines, it is better to collaborate often with the system’s stakeholders that the team supports. Sometimes, we have to if we’re combative, but most times, in a good business environment, we are going in good faith and collaborating — customer collaboration over contract negotiation.
