tl; dr: I work in a small company with a development team of 5 to 10 employees. Lately, we have been asked to submit "scope documents" for all our work before we perform the actual work, without the amount of work required to be considered.
I am worried that I often spend more time writing Scope documents about small improvements than I actually do.
Before I explain my question better, I would like to set some basic views on the situation.
I understand that creating these documents can be considered a training exercise as the team grows and the current members take on leadership roles. I am not against it and I think it is a valuable training experience. I just feel that the documents are not always necessary, which can be a waste of time. As a small company, we feel that we are already under time and resource pressure.
I understand that product and / or project scope is essential when you are looking for a completely new product. I can also see the importance of documents for maintaining order in a structured and distributed development team (many team members + project leaders). When dealing with third-party customers who wish to commission our development work, of course, the scope is mandatory.
I understand the need to ensure that a developer fully understands the request before going to work, but I have to wonder if these small improvements, even if misunderstood, may take more time than writing, Review and revise and sign the appropriate Scope documents.
For the above understanding, excuse the length of this post, but to describe my problems:
My questions arise in situations where our development team makes relatively small improvements to our own internal software. Minor improvements, such as adding a single new button to a web UI that performs a simple operation, or adding a new action handler (basically 1 function) to a backend system.
These little improvements can indirectly Earn revenue as they increase the value of our product, but we do not directly sell these new improvements independently. This leaves little room for scope in terms of cost and return.
All that remains is a scope that lists the expected outcome of why we do it and the expected hourly work stoppage (which is often highly valued). These documents are sometimes moved around with discussions about small issues that have often been applied to the improvement after it has been completed anyway. The documents will be revised to reflect the decisions made in this process.
I can not help but feel that we are wasting a lot of valuable developer time writing these documents, with the slight improvement at the same time needed for writing the original document to go through a first iteration of development , Then the time spent checking the document could be used to validate the code, and instead of revising the code revision and completion document – the end result in this situation is (for me) an improvement, which almost goes as long as the scope / documentation phase has lasted.
My main questions are:
(As part of a small development team)
Are we doing the right scoping / planning and development?
Are there rules of thumb that we should follow in relation to these processes?
Is there a red flag in one of the upper sections indicating that I should adapt my position to the situation?
Is there a way to improve the situation and make everyone happy?
All insight would be very grateful.