Scrum – Role Difference Between Stakeholder and Product Owner

A feature is a distinct element of functionality which can provide capabilities to the business.

A story is a small aspect of a feature which you can use to get feedback from your stakeholders and find out if you're doing anything wrong.

For instance, a feature might be "allow users to comment on articles". The stories associated with that feature might then be:

• save comments
• filter comments for rude words
• limit comments to 400 characters and feed back to users
• add captchas to stop bots spamming the site
• allow users to log in via Google id

etc.

At each stage we can then get feedback as to whether the direction we're taking is useful.

Some teams don't bother splitting features into stories. That's OK.

Planned vs. agile processes for software can be quickly characterized by some pairs.

• Waterfall vs. iterative/incremental
• Watts Humphrey vs. Kent Beck.
• Management driven vs. team driven.
• SEI CMM vs. Agile manifesto.
• Microsoft project vs. burn down lists.
• Interim xyz review vs. scrum stand up meeting.
• Annual release vs. daily build.
• Code inspection vs. pair programming.
• Planning schedules vs. planning game.
• Committees vs. visionaries.

In someways, this question is already answered by the Agile Manifesto, but instead of reading left to right, read right to left.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Some of the comparisons above may be a little harsh, because certainly there is a lot of feature driven development that is practices with planned, and releases may be quarterly (but probably not monthly).

The best thinkers behind planned process were influenced by problems with ad-hoc or poorly suited approaches to software such as were described in Mythical Man-Month. As early as 1968, NATO had a conference on Software Engineering to try to solve the crisis and at that point. I think they had some great innovations. Page 12 of their conference report has a remarkable drawing describing waterfall but with curves instead of boxes. It also includes material about the challenges of estimating software projects. Later, planned software process experts borrowed and stole from QA pioneers like Demming and the many Japanese experts who proved its worth in manufacturing cars and electronics.

I think the best agile thinkers were extremely familiar with planned process, and reacted against its limitations, while retaining some of its strong points. Planned process has not lost all of its relevance, and some would argue it is essential for large projects. Planned is still widely used, particularly in large organizations, but many try to hybrid with agile techniques. Perhaps System of Systems design approaches are planned, but they have a good characteristic of creating small teams which is a more practical place for agile. Planned was sensitive to the need for local tailoring, but expected it would be facilitated by meetings and committees.

Great references on this topic include Watts Humphries books, articles, and technical reports on organizational, team, and personal software process. Contrast those with Kent Beck's introductory sections from eXtreme Programming Explained.

One of my professors described the history of software development something like this:

• 1970s : Tools - a Cambrian explosion of operating systems, programming languages, and tool evolution.
• 1980s : Process - don't blame the people, blame (and fix) the process.
• 1990s : People - empower decision making and communications and interactions among people.