Let's start with the simple idea that Requirements are required items from the project. Capabilities that the project must produce in order for it to earn back its cost to produce. User Stories are a narrative of what the User would like the resulting software to do in some way. It's a story of how a problem or a need could be solved. It's not a requirement that it solve it in some specific manner. Requirements state the specific outcome.
- We need rendezvous and dock with the International Space Station, with 4 Pacs on board, stay for 6 months, return to the landing zone safely. Is a Capability.
- We must use the Low Impact Docking System to connect the Crew Exploration Vehicle with the International Space Station at Node Two using the Pressurized Mating Adapter.
In the software development world...
- We must provide a computer system that is capable of enrolling 750,000 clients in this years health system starting in March and lasting no longer than 45 days - is a Capability.
- All enrollment submissions must use a system that provides remote verification of location, SSN, IRS, and DL data interfaced with Local, State, and Federal system prior to review of benefits defined in XML format in accordance with CMS standards - is a requirement.
Capabilities describe how the produced system will enable the value to be delivered as planned. Requirements describe how the Capabilities will be delivered. Stories are narrative as to how those Capabilities will be used and provide the raw data as to how the Requirements will emerge.
Now For The Punch Line
Using User Stories to predict project performance is also NOT a role of User Stories. User Stories are vague narratives of a customer's desire. They can change, and likely will change as the project moves forward. They are ersatz models of what the software will do when it is done. The naive notion that ...
You can easily predict the release date of a project by just counting the number of Stories
... can only be the case, If and Only If the User Stories never change in their implementation detail, are near exact representation sof what the user wants in terms of Capabilities and the Requirements needed to provide those Capabilities, and most importantly the future is nearly exactly like the past - so the performance that happened in the past will also happen in the future.
As well there can be no emergent risk, no change in effectiveness of labor, nothing will change. This is not only naive, it ignores - some would say willfully ignores - the fact that all project work is uncertain. In the presence of this uncertainty measuring the probability of meeting the planned need date for the planned cost (remember ROI is a core business assessment of the project's performance), and the probability that the needed Capabilities will in fact be delivered as needed cannot be assessed using a measure that is itself vague, emerging, variable in undefined ways, and not actually representative of Physical Percent Complete for the work being performed.
