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.

I still meet a lot of Agile software developers and teams who are not applying proper test automation practices, such as micro-testing, automated integration testing, and continuous integration.

I recently completed a long assignment implementing Scrum and decided that, in the spirit of continuous development and learning, it would be useful to run a personal retrospective while between jobs. This paper articulates some of my key findings and probably confirms what many Agile practitioners already suspect. I have suggested some techniques and ideas that may be effective in managing future transitions to Agile

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.

The ability to deliver business value earlier and more often, increase productivity, and improve employee morale is compelling many organizations to embrace Agile approaches to software development. There is a wide array of training courses, consultants, and books available to help teams learn the basics of agile development, but these often focus on the team-level challenges, and overlook some of the larger organizational issues that may either help or hinder the transition to this new way of thinking and working. This article attempts to outline areas where many organizations encounter difficulties in their embrace of Agile, in hopes that others can be better prepared to meet these challenges.

When Agile meets 'Big Design', the result can be frustration on both sides. Is it possible for database development to to easily coexist with Agile methodologies for application development? This article suggests that the technical solutions already exist, and the dissonance is more due to cultural and organisational problems.

This article discusses a graphic that shows the status of larger projects, how to gather the information needed, read the status chart, and when needed, show more detailed breakdown for each subproject.

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.

This article describes a new metric for the number of Running Tested Features delivered in a product and how this leads a team to develop in an agile manner.

The Risk-Driven Model guides developers to do just enough architecture by identifying their project’s most pressing risks and applying only Agile architecture and design techniques that mitigate them.