How we schedule work requests from other projects
Over the last couple of months we’ve had a number of requests from people and projects, somewhat out of the blue, asking for pieces of work to be completed with a deadline within only a couple of days of asking.
We often say no to such requests, which can take people a little by surprise. But it’s usually not a downright no, it’s more of a ‘not yet’. This post goes some way to explaining why this is.
Fixed time, fixed resource
The reason behind often saying “yes… just not yet” is to do with the time budgets we have allocated for working on different kinds of work each sprint. (We stack up our work in blocks of two weeks, which we call sprints.)
In agile-speak this is the principle of fixed time and fixed resource. In our team that means:
- a fixed resource of 10 team members, and
- a fixed time of 725 hours per fortnight (assuming a work day of 7.25 hours).
That’s why I like the analogy with financial budgets. Like our monthly pay packets, we can’t just go out and blow the lot on whatever we want. There will be fixed payments that we need to make, and it would also be wise to fix budgets for certain categories (food, clothing, fuel, entertainment, etc).
Our time budget
That’s what our universe of work is all about. It is essentially our big-picture budget sheet.
The universe of work lays out for us the immovable meetings and commitments that we have and the regular bits and pieces that we must do to keep things working. It defines the framework for our sprint, it beats out the rhythm for the fortnight:
- Daily stand-up meetings every morning, with a period of 30 minutes beforehand to prepare.
- A start-of-sprint kick off and planning meeting on the first Monday.
- Fix-it Fridays, and 5% time for personal development.
- A strategy meeting each Wednesday, and a meeting with the business visionary to settle on goals for the following sprint.
- A meeting with software developers to discuss the road map for our digital pattern library.
- A demo on the final Thursday.
- And an end of sprint retrospective.
Once we have factored these into our calendars we have only 326 hours left to split between project (229 hours) and business as usual work (97 hours).
Into this steady heartbeat we insert our work: business as usual (work to run the business) and project work (work to change the business). We check emails and we blog, we write the digital communications team newsletter, we meet with the digital advisory board (the DAB), and our portfolio board (DCPB); we meet and discuss, we plan, and we write, we develop and we edit. And we consult.
Consultancy
We define consultancy as any piece of work for a project or programme, outwith our own portfolio, that we are not managing. Sometimes people are just looking for advice or guidance on a solution, sometimes they want us to quality-assure or evaluate a possible solution, and other times they want us to help as solutions developers to help them create the solution itself.
For consultancy work we currently set aside a maximum of 20 hours each sprint – that is, two hours per team member per sprint. Obviously, should our team size change then the amount of time we have for consultancy would also adjust relatively.
Like any good budget, we track how much consultancy we use up each sprint. And if we reach 20 hours then we cap it there and any further requests get bumped to the next sprint. We usually can’t borrow time from other budgets, and certainly not project budgets, because the time for those should be fixed.
At the beginning of many sprints we already have an idea of who wants our help, and our consultancy budget has already been allocated. That’s why the answer to ad hoc requests for work to be completed within a couple of days is often “No, well… yes… just not yet”.
Conclusion
The key to securing our time is advance notice. Let us know as soon as you do that you may require our time and expertise; if you can also give us a rough idea of when and for how long, then even better.
Because we work in two-week sprints, we prefer if you can give us at least a fortnight’s notice. That gives us time to include it in the next sprint.