Traditionally, software development projects started out with an idea and then tried to identify all the requirements needed to make that idea "complete" for the intended users. This long process was expensive (and sometimes ended in a “no-go” decision only after a great deal of money was spent) and did not place enough emphasis on value returned for the investment made. Agile has a tool that can help organizations re-focus on return on investment: value-driven user stories. Value-driven user stories are created specifically to link features with their users and the value the features have for their users. They can be created from a list of high-level features or a list of values and users centered on a general idea.

Writing good User Stories is difficult for new teams starting with a new agile project. Mistakes made at that point lead to wrong Test Cases, wrong understanding of requirements, and the worst of all wrong implementation which can be direct cause of rejecting the deliverables of the iteration. Lets take a look at the five most common mistakes people make writing User Stories.

This article describes a Lean and Scalable Requirements Information Model that extends the basic team‐based agile requirements practices to the needs of the largest, lean‐thinking software enterprise. While fully scalable to all levels of the project, program and portfolio levels, the foundation of the model is a quintessentially lean and agile subset in support of the agile project teams that write and test all the code.

Sizing software requirements is an essential best practice in software project management for forecasting the work effort required for software development projects (and other related metrics). Arguably, the currently most accurate software metric for measuring the size of software is the International Function Point Users Group (IFPUG) “function point,” which has the ISO standard ISO/ IEC 20926:2009. Function points basically measure the size of the data flow and storage through the software, which we define in this paper as “functional” requirements. But function points do not measure other software requirements, which also require work effort resources. IFPUG has recently completed a successful beta test of a new method to assess the size of other, “nonfunctional” requirements, which when used in conjunction with function points should further increase the accuracy of software forecasting.

While aspect-orientation originally has emerged at the programming level, it now stretches also over other development phases. There are, for example, already several proposals to Aspect-Oriented Modeling (AOM), most of them pursuing distinguished goals, providing different concepts as well as notations, and showing various levels of maturity.

This article describes the background and application of user stories, which is the primary requirements artifact agile teams use to carry the customers value stream though development.

Active Architecture is a type of documentation that is based on User Stories and helps to bridge the gap between User Stories in Agile Projects and large design deliverables on Traditional projects.

Very detailed case study, illustrating how additional practices (problem frames) can be used in a leightweight method like XP. Not every agile purist might agree with the advice, but the research is certainly worth studying.

Entire books have been written about many of the XP developer practices; no book has more than 11 pages about customer practices.....

This article ties a rather abstract and developer centered concept (story points) to the financial side of business (spreadsheets and ledgers). Making this connection is essential for management.