1. The customer is part of the team that produces the product, so they can indeed pile wish upon wish. But they are also part of the planning process for which story is included in which sprint, so they get immediate feedback on which wish will take how long to implement, and what other wish will be postponed because of it. This creates a natural counterweight. (Whereas in old-fashioned, strictly segregated requirements engineering and development, such feedback virtually never happens, and the customer has no idea which features would take how much time; sometimes the customer reps even actively lie about it.)
2. Differs from method to method, but in general, the focus is on getting requirements from people closer to the actual users of the finished product, rather than from their managers, their procurement department, or even their sales reps.
3. Pretty much part of the same arrangement as in (1): the customer should be present when the feature is planned, implemented, tried out and tested. If during all those steps, they don’t notice that they don’t actually want it, well… some people truly can’t be pleased, and even agile methods are helpless against that.

How do agile methods deal with the problem of feature creep

The main way is that Agile methods are typically based on the idea of a backlog and release planning. Anything that a user wants can go in the backlog. At regular intervals, the users are expected to prioritize the backlog, to set the features that the team works on.

Users are not, however, allowed to request new features for the current iteration. The definition of “feature” is somewhat blurry, though: at the start of the iteration, the programmer knows just enough about the requirements to give a rough estimate of time. During the iteration, the developer will work with the user to refine the requirements. As this happens, the agreed-upon feature may turn out to be more complex than originally expected. In a perfect world, user and developer settle on “good enough,” and defer enhancements to the backlog.

In the real world, sprints occasionally fail (don’t produce anything) because user and developer can’t agree on reasonable scope. After a few failures, the team (which includes the users) have to face their disfunction, and figure out a way around it.

Who does the requirements engineering in agile methods

The team, which includes developers and users. The idea behind Agile methods is that users rarely know what they want in the level of detail needed to implement a production-quality piece of software. There are always corner cases, and those should come out as the developer analyzes the feature.

The big issue is how those requirements are captured. There’s no reason that you couldn’t produce a formal requirements document as part of an Agile methodology, but most teams see that as anti-Agile. Some teams use testcases as the requirements, and a well-written suite of integration tests is one of the best formal requirements documents you can get. A wiki page that captures the discussion between users and developers is also reasonable.

Unfortunately, many teams see Agile as “we don’t need no stinkin’ documentation,” and end up in arguments six months down the road. Which occasionally spells the end of “Agile” at that particular company.

Do you validate in MSF / agile methods if your product does what the customer wants and the user needs before shipping it? How do you do it?

The user says “this meets my needs.” This happens at the end of every iteration, and when enough needs are met the project releases. Then the enhancements start.

These two philosophies seem to contradict each other, but they can coexist. Just because the developers don’t have direct contact to the users, doesn’t mean that there is no communication between them.

The communication happens through the customer relations people who ask the customers for their requirements, translate them into the language of the development team, and give the developers clear instructions they can follow. Then they present the prototypes to the customers, aggregate their feedback and report it back to the development team. That way the developers can concentrate fully on the development.

The Microsoft philosophy is based on the assumption that programmers and customer relations are two entirely different specializations with entirely different training. The programmers are trained for talking to machines while the CR people are trained for talking to humans. Each one should do the job they are trained for.

The agile philosophy, on the other hand, assumes an eloquent software developers who can both write elegant code and have the social abilities to deal with the users. Excelling both at social and at technical skills is an ideal we should all strafe for, but let’s be honest: most people are more enclined for either one or the other. Those who can do both are a rare (and extremely valuable!) elite.

This is from an agile point of view

1. Feature Creep
Feature creep in an of itself is not a problem and is in-fact encouraged in agile. The customer should be able to request new features as they occur. The scope should be able to change, and dealing with that change is a main tenant of agile.

Where is does become a problem is if the team has committed to a set of work (ie a scrum sprint) and the requirements change. Hopefully by the time the planning meeting is over the feature is well defined and can be committed to and hopefully won’t change in the next 2 weeks. Before the planning meeting the feature should be allowed to change as much as they want.

My view is that the team should be able to absorb a little change during the itteration. If it’s just additional work on top of the feature, add it to the backlog. If it no longer makes sense to do the feature, either fit it in or remove the feature all together. If the feature is already done, add the change to the backlog. What ever you do, don’t implement a feature that is no longer required. In any case, the Product Owner should be involved as they are the ones who have to “accept” a feature as it’s done

A way of limiting scope change is to write good user stories. A good user story clearly states what a feature is about. It is also small (ie < ~2 days of work), so it needs to drastically change for it to have an impact.

2. Requirements Gathering
Agile tends to be pretty quiet on who does the requirements gathering. It could be the Product Owner, developers, BAs or the end users. What is important is that there is a single backlog (program of work) and that it is prioritized by a single person (the product owner). The product owner can get input from others and organise it using any method they like, but the buck needs to stop with him/her.

3. Validation
If you are using an iterative method (eg scrum), the validation is usually done at the end of iteration presentation.
If you are using a continuous method (eg kanban), the validation is done continuously. The task is not done until it is validated.
I usually get my team to regularly pull in the right people and go through the feature with them.

An alternative is to just ship the feature and adjust it based on feedback. You can only do this if you shipping software often (daily->fortnightly).

We work in a large corporation where our client is our Client Services department and our Product Owner is the head of that department. She has one “under-head” that assists her with everything.

To answer the question of developers talking to the client: In Scrum/Agile the ‘client’ would be the Product Owner (PO).
It is VERY important for the client to come into contact with the developers working on their product. It helps in Sprint Planning and Backlog Grooming to get the understanding of the developers on par with that of the client. So that what we build is damned close to what the client expects. But sometimes the nature of the client or the environment of the relationship is such that the two parties should rather not talk to each other. In cases like this one would get a Proxy PO who can communicate with both sides. Someone who can still give the developers the personal connection to the ‘client’ while keeping the client up to date with what is happening with their product.

I will attempt to answer your sub question, of dealing with feature creep, by explaining how we deal with it: With backlog grooming we can learn what the client has added to the backlog and what their priorities are. Here they can add what because in the corporate environment the one product we work on is long term. But if they start adding stuff during a sprint (after we have committed to X-amount of stories/effort points) then we simply size the new work and label it as “unplanned”. Unplanned work can be added to the Sprint but then we either remove an equal amount of point from the initial list or we add it as negative points to our Sprint graph. This allows the client to see the impact of their decision on what they wanted for the sprint. Should they not get all the original features or should the original commitment not be met at the end of the sprint it is made clear it was their fault.

This happens but once or twice and then they stop doing it. 🙂 But is does require the developer team to stick to their guns and not let the unplanned work “fall through the crack” and be done anyway.