> Unplanned work happens unexpectedly, but it’s not unexpected. You know that there will be bug reports, you just don’t know when, where, and in what shape they will come up. The only thing that is certain is that they will appear.<p>I am tempted, half tongue-in-cheek, to suggest simply scheduling it:<p><pre><code> 09:00-09:30 get coffee and morning standup
09:30-11:30 work on project A
11:30-12:30 lunch
12:30-14:00 deal with the emergency of the day
14:00-17:00 work on project B
</code></pre>
And for all that that's exaggerated for humorous effect, I actually <i>have</i> played with scheduling blocks of time for catching up on Slack messages, which is pretty similar really.
I kind of like the article take on how to handle emergent issues, but I don't like that it still sort of silos software development into two parts -- planned and unplanned.<p>I hate the term "unplanned" to describe this kind of work. By using a very narrow definition of "plan", for work "organized and scheduled in advance" but only within projects and roadmaps, it sort of works. A more informal usage of unplanned, though, suggests a kind of blindness to the reality of software development and maintenance.<p>The reality is that the effort in software development isn't easily divided into these streams. The article fails to address an important consequence of putting effort into fighting fires: the project plans and roadmaps of the affected teams <i>will</i> be disrupted. This is where the term "unplanned" really fails, because if the organization never takes into account the effort taken to address issues and emergencies, the plans are worse than having no plan at all.<p>On a different note, one place I consulted with had its planning and tracking tool (Jira-like Azure DevOps) directly feed into its accounting system, such that different types of work were bucketed into different amortization flows. Planned work was a capital expenditure (CapEx), while anything funneled into Unplanned became an operating expenditure (OpEx). Any accountant that knows the implications of CapEx vs. OpEx can see where this is going. This company had a <i>lot</i> of bugs and issues that were left unaddressed.
Put whatever unexpected work comes up into a general inbox somewhere, without preprocessing it (i.e. without figuring the next steps). Then periodically process what's in the inbox (figuring out the next steps and scheduling them), once a day, once a week, whatever. Also, buffer for unexpected stuff in your deadlines, in my work it's generally 40%.
Hi. Ty for the article and responses. Is there a similar open source, transparent, and modifiable tool using things like git or emacs org mode? Please don't flame the noob.
Absolutely nothing in this actually covered how to plan for unplanned work. While yes becoming aware of issues quicker and preventing things from falling through the cracks is great and all, it's still strictly post hoc. "Dealing with unplanned work" would be a better title.