Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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?


migration rejected from stackoverflow.com Feb 19 '14 at 12:07

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by gnat, MichaelT, GlenH7, Kilian Foth, Bart van Ingen Schenau Feb 19 '14 at 12:07

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

4 Answers 4

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.


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.


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.


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.


Not the answer you're looking for? Browse other questions tagged or ask your own question.