How do you address or avoid problems with new features being quickly added to the scope of a project?

Question

I am working on a project with a single developer (so far) and myself in a testing role. There are a bunch of new features being added. The project is .NET4.0 based, but some users need 3.5 compatibility, support for Silverlight and Windows Phone 7. These are all features wanted by users, but with the number of people participating in this project, it might get out of hand.

What experiences do you have in controlling feature requests and scope creep?

Answer 1

It's the common plague of a software project. The best advice I can offer you is do them a very few features at one time, test heavily -- look into test driven design if you haven't already -- and release partial product builds often. Without exception, every time I've been in one of these situations, at least some of the users requesting features will see the feature you implemented and say "oh, that's not what I wanted at all!" The earlier you can show them something, the less rework you'll face.

Answer 2

Collect the requirements as user stories and put them in a backlog for the future, then determine which future releases these features will be included, based on what you can do in a given unit of time of an iteration and some method of prioritizing the features (the latter will need some feedback from the business concerns). If you organize your work into these manageable iterations or "sprints", it will keep the workload from overloading both the developer and you the tester, as well as managing the expectations of the users.

A nice tool for managing this pipeline is Agile Zen.

Answer 3

In addition to the other good ideas raised already...If the requirement is new, and you are near the point of releasing the product, make sure to let the PM and customer know that these new requirements are out-of-scope for v1.0.

The PM should consider v1.0 completed and convey the reason politely to the customer.

Main point is - Don't start on implementing the new requirements such as the above ones under the current release.

In my opinion, the requirements you have mentioned show that the requirements gathering was not adequate. Certain things should have been picked up during requirements phase (like support for Silverlight and Windows Phone 7) - These, to me, are not minor points.

Answer 4

depending on the scale of the project, and on the number of customers, I'd look into creating a 'liason' function (or 'project manger'). (on a small project, by the way, it can be an extra role assigned to one of the persons involved).
That person's job would be to accumulate all the different requests from the customers, and decide what will be done, and when.
also, make sure that you document beforehand what you're going to do (either by use cases, screen shots etc..) and have your project manager approve it with the customers. That's the best way to avoid 'that's not what I wanted' complaints that @Charlie Martin referred to.

Answer 5

I think you first need to decide, as a product team, what a reasonable release schedule would be - can you release a new version every week, every two weeks, every two months, etc? From that, estimate how many development hours you have available for each release (factoring in that you have a single developer, and that time needs to be reserved for design, coding, documentation, re-factoring, support, writing deployment scripts, surfing stackexchange, testing, etc.)

Then, keep track of all requested new features, enhancements, and bugs. For each, provide a rough development estimate. You will now have a list of items, their "cost" (in development hours), and an amount you can "spend" for each release.

The next step is to somehow select the items to be included in the future releases. If you can establish a single point-of-contact - a "product manager" or a "user representative" or even a small working group - that's great. That person/group has the final say into what is included or not in each release. If it's not possible to define a single person/group for this, you can try surveying the user base - ask the users to simply rank the features that are most important to them. if you do this, to keep it simple, I would only include new features being considered, in the survey - leave out bug fixed, small enhancements, etc.