At Affino we work to a number of parallel schedules - these cover Affino Core Development, Projects, Custom Functionality, Bug Fixes and Incidentals as the key ones. The working day is mostly divided into 3, with the first third typically dedicated to solving customer support issues and bugs, while the latter part of the day allows the developers to focus wholly on their more complex tasks - without distractions. Of course the algorithm is slightly more complex than this as each developer has specialist areas, and other more communal skills which overlap - meaning that some developers dedicate more time to support and core development while others work almost entirely on projects.
The key working cycles are the fortnightly development sprints which in point of fact often get scheduled as much as 6 or 8 weeks in advance. With this kind of work, there is a lot of guesstimation involved, and each task is broken down into a number of practical units which are allocated against hourly slots. As so much of the work we do is brand new, as often as not, the final task development will likely take slightly longer, so there is a degree of spill-over between sprints. With certain tasks having to be extended forwards - very occasionally across a number of additional sprints. Note also that requirements can change, and as new actualities are revealed, projects can easily become extended as various feeder tasks don’t happen as quickly, and developers are left waiting for specific input - often to do with 3rd party APIs and Data.
As a commissioning client, you should know that there is really no way to get around the schedule for larger tasks - they require long run-ins on the schedule for efficiency and effectiveness, and thus have to be part of the agile sprint methodology. Anyone commissioning a project will be sprint-scheduled once certain sign-offs / milestones / benchmarks are reached - and there will of course be a degree of contingency that needs to be factored in - the more complex the project, the greater the contingency. Same goes for the number of unknowns that exist in the brief.
At the other end of the scale we offer Prepaid Development Days - this is where customers pay at least one day’s development in advance, usually more. If the task/s are relatively minor, then they can be more easily fitted in around the larger schedule - as smaller units (like the pebble + sand jar analogy), on occasion some of the early 1/3 rd support slots might be able to be used for small prepaid tasks if there is less call for the various support type tasks happening concurrently.
The benefits of Prepaid Development Days are two-fold - you get a better rate, and Affino simply subtracts the number of units or development hours from your total, and what you have remaining can be utilised for further custom tasks occurring later. The alternative is to pay custom project costs for which the minimum unit is 1/2 a day, has no carry-over, and requires more longer-term scheduling. No project or custom development tasks start until the up-front payments are made.
Prepaid Development may result in very slightly more outlay initially, but you pay less per unit, and typically see your task/s scheduled / completed sooner. The same goes for any follow-on or follow-up tasks too, as long as you have funds remaining in your prepaid development account you have access to accelerated and lower-cost development. Beware that larger unit Prepaid Development tasks will need to be sprint-scheduled, but as funds are likely already in the system, their progress will be quicker and more efficient than the other route.