Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

What factors are taken in consideration when adding/eliminating features, and who is responsible to add new feature in any project or to change -lets say-

  • UI components to increase usability
  • new module or new functionality;

The case I'm asking about there are no contract or SRS document involved -which means no request from the clients to add this specific feature or module.

share|improve this question

migrated from sqa.stackexchange.com Jul 9 at 22:25

This question came from our site for software quality control experts, automation engineers, and software testers.

    
my reason was to know, is it eligible to spend time and money over modules and features that not even useful for users and eventually they get removed, your answer was a such help. –  user6336 Jul 9 at 9:12

2 Answers 2

This greatly depends on the used software development methodology, but in all cases there should be a central point to collect new features and a person to schedule a kick off of the process from design till implementation.

In the SCRUM methodology (a popular agile process framework) there is a role called Product Owner. This is the person who decides what goes in and what not. He represents the client, defines what the business value is and prioritizes new features. See the great 15 minutes Product Owner in a Nutshell video.

One of the Agile manifesto principles is:

Simplicity--the art of maximizing the amount of work not done--is essential.

So a drive to minimize unrequested features is a solid one, since you will have to maintain the feature and make sure it is covered by testcases. Adding unneeded features to the software development life cycle will only increase the total cost on the long run.

share|improve this answer
1  
... and the relevant rule is YAGNI "you ain't gonna need it". Don't waste time implementing feature which only programmers think user might want. –  Peter Masiar Jul 9 at 16:26

As a basis for all our development cycles, from when we were Waterfall, to Agile and now Iterative, we have always had a change request process.

If a change to the system is new and not a bug, then it should be raised with the individual who own's the project manager/product owner. That change should then be assesed to ensure it meets the needs of the business, the cost (Physical and resource) and the impact to timelines.

I have worked on a few deliverables, where this has not been the case. In each instance, the unverified change has lead to the timeline extending, more resource being required and more bugs being found. I have also found it encourgaes people not to communicate, so test environments become unstable and bugs are found in live as a result of testers not knowing that the change existed.

share|improve this answer
1  
This question is appropriate from a testing point of view. In my current position, the development teams do not feel there is need to communicate change and that it is there decisions. This has now changed as result of testing highlighting the impact to the company. It is also not the first time I have seen the test teams just accepting this as they are not as respected as the development teams at that work place. It depends on the environment and how important the developers see testing. –  user3793094 Jul 8 at 14:19
    
its not up to developers to decide if the testers are important or not, the upper management is responsible of that matter, at some point they should support testing dept. and yes testers face that a lot. –  user6336 Jul 9 at 9:09
    
That is correct, although i was merely making the point that the question was relevant from a testing perspective –  user3793094 Jul 9 at 9:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.