Summary and Reason for This Post
Speaking for myself as a programmer, I am in a profession requiring much insight into complex technological systems, their workings and similar things in which someone in another profession may have a difficult time assessing the work involved to complete a task. This often leads to the work done being:
- Taken for granted.
- Not properly understood.
What I'm here to talk about and discuss is something that does not only occur in software engineering / programming as a profession, but since that is the case from which these thoughts have arisen, it will also be the case I use in my examples.
As such, the reason for this post is to present a solution to this problem and to request your thoughts, comments and feedback to my solution.
I call this scale the Programmer's Saturation Scale, in which superior staff or others (e.g. company presidents, clients etc) without technical insight can easily get a single value telling how much work is currently on their development team.
My suggestion for the workings of this scale is as follows:
- 100% Saturation
100% Saturation is achieved when every single developer on the team has a pre-set timespan of fully occupied work time ahead of them. 100% Saturation is meant to relay that no more tasks can be added without either disrupting current schedules or expecting a wait for the task to be finished.
- 0% Saturation
0% Saturation indicates that the developers have nothing to to whatsoever.
- Optimal Timespan
The Optimal Timespan is what defines 100% Saturation. A software maintenance team who's main focus lie in system enhancement and enrichment may have an Optimal Timespan of maybe four weeks. A team working with Scrum or similar methods may have an Optimal Timespan of a single week, allowing for short, timely sprints and release on a weekly basis, while a game developer producing a new title may have an Optimal Timespan of six months.
This means that when there is always the set amount of work (i.e. the Optimal Timespan), the team can work optimally and get the best amount of work done with the highest quality, without long waits or worn-out developers.
With this scale, an optimal value can be presented to the company lead, clients, or similar other individuals to optimize the planning of tasks, scheduling and understanding of the current workload, while still customizing the situation after the development team's own methodologies and work situation.
The scale is not intended to replace hourly work logs, long-term planning of future projects or anything corresponding to such, but to complement a continuously working development team with a value showing the current work load.
Having seen situations where double full-time work is expected, all-nighters are taken for granted and still being unable to relay that this is too much work to have for more than a short time, I hope that this scale will easily communicate the situation for the, in this case, developers. It is easy to understand "Our current Saturation level is at 250%" for someone who does not understand what kind of performance is required per-task. It is also easy for an issue control system to always generate this value.
I would greatly appreciate your thoughts on this, both from developers who would be the users of this system, and from other professionals if they would consider this value to be easily understandable.
Many thanks for reading this post, and for your thoughts and views.