The requirements are developed as User Stories – simple statements in business terms. Write them on cards so they can be readily re-ordered.
Customers and Developers work at the white board to ensure that all present understand each requirement. Some stories may need to be broken into Tasks – particularly if the work may need different skills but also because in a n-tier system there may be n or more tasks to one Story. Pairs place estimates on each Task.
The user Stories are prioritised in terms of the User’s needs and priorities. A Release interval of 3 weeks is set. [This is an experience-based figure.] Those Stories that can be delivered in the first release period are re-estimated by all pairs.
The User may have new Stories, or wish to vary Stories but may see a need for different priority on existing stories. So the Stories are re-allocated to future releases and commitment made to the next release.
Avoid generalisations, architectural approaches, excessive parametisation. Challenge words like “All” or “Every”. Triage business cases – can we deliver code which handles the most common cases and provide a work-around (possibly manual) or use the legacy system for the remaining cases?