One of the great things about working as a consultant is the ability to try out many different ideas and adapting your personal favorite process to include things that work. This article gives the details about user story estimation techniques that Jay Fields has found effective.
User stories, a common format for capturing agile requirements, could be more focused on business value. A traditional format for stating a user story is: "As a <type of user> I want <some functionality> so that <some benefit>." A value-centric replacement would be: "In order to <achieve some value>, as a <type of user>, I want <some functionality>."
In this presentation recorded during QCon London 2007, Rachel Davies, director of Agile Alliance, talks about the Agile development cycle starting with user stories and planning the releases.
For those using User Stories, getting them right is one of the difficult aspects of an Agile process - they can drive or bog down your work. Pat Kua recently addressed a key question: How much detail should you put in your story? The answer, of course, is "it depends" on where you are in the process.
Planning the features to be developed is an important part of software development. In Scrum, the list of features desired but not yet implemented is typically called the backlog (or product backlog). This is meant to be lightweight, but can it still be wasteful?
At Agile2006 InfoQ interviewed Alistair Cockburn, methodology creator, author and long-time leader in the Agile community. Topics discussed ranged from the history of the Agile movement to the future of methodologies, with a look at User Stories and Use Cases along the way. This interview uncovers how his research for IBM may have sparked the creation of the Agile Manifesto.