6 ms·

Planning for Unplanned Work in Linear

yjftsjthsd-h 3y ago
> 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. I am tempted, half tongue-in-cheek, to suggest simply scheduling it: 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 And for all that that's exaggerated for humorous effect, I actually have played with scheduling blocks of time for catching up on Slack messages, which is pretty similar really.
- meheleventyone 3y ago
  I work with a team from PT->CET and am in UTC-0 so no joke the first thirty minutes to an hour of my day is catching up with the rest of what happened the previous day and what’s going on at the start of the next day. I don’t need to schedule it because thankfully my morning is usually quiet but it’s common enough I mention it in my work log. I don’t think this is unplanned work so much as unrecognised work. Few Gantt charts etc. keep track of that overhead like the overhead from ‘surprise’ tasks.
  - candiddevmike 3y ago
    I love multi timezone teams because it forces everyone to work asynchronous. I find those environments to be really relaxing and flexible.
    - meheleventyone 3y ago
      To an extent, for me at least I get a great block in the morning to early afternoon then a lot of meetings that are mostly 1:1s with direct reports and strategy/planning clustered around PT morning and my evening. I like that though but it’s a struggle to not be brain dead especially with people freshly awake and full of coffee.
    - esafak 3y ago
      If your company is sensible. Some mandate "core working hours" based on the HQ, and meetings around the clock.
- adastra22 3y ago
  Why is this exaggerated or humorous? That's literally what I do. Works great.
  - veidr 3y ago
    Same here. And I put in my calendar to make it obvious to others that it's there. I used to put in in the issue-tracker, too, but lately our team manager started reducing the "normal" expected story points to a level that reflects the time left in the iteration after the average amount of "unplanned" work is considered, which also works.
  - yjftsjthsd-h 3y ago
    I guess the joke is that I would have liked to imagine that I didn't have an emergency a day like clockwork. Let me keep my fantasies;)
- tut-urut-utut 3y ago
  I always hear these 9 to 5 references about working time. As someone in Europe where lunch break doesn’t count as working time, this would amount to 7 work hours. Here the norm is 8 hours. Does lunch break in the USA counts as working, or you typically work 7 hour days?
  - Projectiboga 3y ago
    Depends, but traditionally in the USA white-collar jobs are 9-5 with time for lunch.
cratermoon 3y ago
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. 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. 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 will 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. 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 lot of bugs and issues that were left unaddressed.
- lizard 3y ago
  > 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 will 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. The article likely glosses over these particular details because it's a sales pitch for an app that offers a, seemingly, smooth flow to get "unplanned" work into the "plan." The "plan" just being the ticketing system where work-to-be-performed is assigned, not the roadmap. You're not wrong that "unplanned work", of any form, can disrupt your timelines. And that why the features they are describing, that are separate from the assigned work, are important. They require someone to explicitly acknowledge and accept the costs of that work before adding it to the "plan." That said, your roadmap, like it's analogous counterpart, generally won't be that specific. It's just there to layout the direction and highlight important landmarks. You don't use the roadmap to draw every gas stop or who is driving each stretch of road on the road map because it's hard to anticipate those details and expensive to update when things go awry. And even if you try, sometimes you just want to take a detour and see the Largest Ball of Yarn because you need to stretch your legs and it's only a few miles out of the way. Your roadmap shouldn't care about any of that, it's just there to help you get back on track when you're done. But once you get to the car, you make a plan. You decide who is going to drive first and how far you expect to go. And you can change that plan when the fuel tank doesn't get you as far as you thought, or a poor night's sleep catches up with you sooner than expected, or there's a rock shop on the side of the road, because you can ask the other people in the car whether its worth arriving a little later to look at some cool rocks.
asicsarecool 3y ago
Has anyone here used Linear? Looks interesting
- lijok 3y ago
  Been using it at work for a bit over a year now. It's great, very lean, snappy. They're deliverying features at crazy speed too. A breath of fresh air after having had to use Jira for way too long. Can highly recommend.
- Minor49er 3y ago
  I've been using it at my job for about a year now. It's pretty decent. Their support team is also highly active on Slack, so if you run into any trouble, they will help you resolve it right away
- lmm 3y ago
  I use it. It's ok. Slick, simple, gets the job done.
- aniforprez 3y ago
  After wading through the molasses that is Jira, Linear is very good. Very fast and snappy though not as extensible and configurable as Jira of course
- aerhardt 3y ago
  Started using it a few months ago. It’s a normal issue tracker feature-wise. Doesn’t seem to reinvent the wheel, functionally. Where it shines is in UX: crazy fast and snappy, great layouts, keyboard shortcuts, look and feel, etc. I’m at a point where I go “ugh” if I have to use anything else.
- cornel_io 3y ago
  Yes - I don't hate it. ...which is literally the highest praise I have ever given and probably ever will to issue-management software. They correctly realize that we mainly want to not notice the software, which is something that every competitor gets wrong. What I can't figure out is how they possibly got funding in the reddest of red oceans with a pitch that couldn't have been much more than "we'll make Jira but not suck" (that's essentially all it is), but I'm glad they did.
dmos62 3y ago
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%.
- adastra22 3y ago
  Sounds like the GTD approach. Works well for me too!
jjk166 3y ago
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.
esafak 3y ago
They had to call it an "Ask" :(
marginatum 3y ago
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.

> 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. I am tempted, half tongue-in-cheek, to suggest simply scheduling it: 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 And for all that that's exaggerated for humorous effect, I actually have played with scheduling blocks of time for catching up on Slack messages, which is pretty similar really.

meheleventyone 3y ago
I work with a team from PT->CET and am in UTC-0 so no joke the first thirty minutes to an hour of my day is catching up with the rest of what happened the previous day and what’s going on at the start of the next day. I don’t need to schedule it because thankfully my morning is usually quiet but it’s common enough I mention it in my work log. I don’t think this is unplanned work so much as unrecognised work. Few Gantt charts etc. keep track of that overhead like the overhead from ‘surprise’ tasks.
- candiddevmike 3y ago
  I love multi timezone teams because it forces everyone to work asynchronous. I find those environments to be really relaxing and flexible.
  - meheleventyone 3y ago
    To an extent, for me at least I get a great block in the morning to early afternoon then a lot of meetings that are mostly 1:1s with direct reports and strategy/planning clustered around PT morning and my evening. I like that though but it’s a struggle to not be brain dead especially with people freshly awake and full of coffee.
  - esafak 3y ago
    If your company is sensible. Some mandate "core working hours" based on the HQ, and meetings around the clock.
adastra22 3y ago
Why is this exaggerated or humorous? That's literally what I do. Works great.
- veidr 3y ago
  Same here. And I put in my calendar to make it obvious to others that it's there. I used to put in in the issue-tracker, too, but lately our team manager started reducing the "normal" expected story points to a level that reflects the time left in the iteration after the average amount of "unplanned" work is considered, which also works.
- yjftsjthsd-h 3y ago
  I guess the joke is that I would have liked to imagine that I didn't have an emergency a day like clockwork. Let me keep my fantasies;)
tut-urut-utut 3y ago
I always hear these 9 to 5 references about working time. As someone in Europe where lunch break doesn’t count as working time, this would amount to 7 work hours. Here the norm is 8 hours. Does lunch break in the USA counts as working, or you typically work 7 hour days?
- Projectiboga 3y ago
  Depends, but traditionally in the USA white-collar jobs are 9-5 with time for lunch.

cratermoon 3y ago

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. 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. 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 will 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. 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 lot of bugs and issues that were left unaddressed.

lizard 3y ago
> 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 will 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. The article likely glosses over these particular details because it's a sales pitch for an app that offers a, seemingly, smooth flow to get "unplanned" work into the "plan." The "plan" just being the ticketing system where work-to-be-performed is assigned, not the roadmap. You're not wrong that "unplanned work", of any form, can disrupt your timelines. And that why the features they are describing, that are separate from the assigned work, are important. They require someone to explicitly acknowledge and accept the costs of that work before adding it to the "plan." That said, your roadmap, like it's analogous counterpart, generally won't be that specific. It's just there to layout the direction and highlight important landmarks. You don't use the roadmap to draw every gas stop or who is driving each stretch of road on the road map because it's hard to anticipate those details and expensive to update when things go awry. And even if you try, sometimes you just want to take a detour and see the Largest Ball of Yarn because you need to stretch your legs and it's only a few miles out of the way. Your roadmap shouldn't care about any of that, it's just there to help you get back on track when you're done. But once you get to the car, you make a plan. You decide who is going to drive first and how far you expect to go. And you can change that plan when the fuel tank doesn't get you as far as you thought, or a poor night's sleep catches up with you sooner than expected, or there's a rock shop on the side of the road, because you can ask the other people in the car whether its worth arriving a little later to look at some cool rocks.

asicsarecool 3y ago

Has anyone here used Linear? Looks interesting

lijok 3y ago
Been using it at work for a bit over a year now. It's great, very lean, snappy. They're deliverying features at crazy speed too. A breath of fresh air after having had to use Jira for way too long. Can highly recommend.
Minor49er 3y ago
I've been using it at my job for about a year now. It's pretty decent. Their support team is also highly active on Slack, so if you run into any trouble, they will help you resolve it right away
lmm 3y ago
I use it. It's ok. Slick, simple, gets the job done.
aniforprez 3y ago
After wading through the molasses that is Jira, Linear is very good. Very fast and snappy though not as extensible and configurable as Jira of course
aerhardt 3y ago
Started using it a few months ago. It’s a normal issue tracker feature-wise. Doesn’t seem to reinvent the wheel, functionally. Where it shines is in UX: crazy fast and snappy, great layouts, keyboard shortcuts, look and feel, etc. I’m at a point where I go “ugh” if I have to use anything else.
cornel_io 3y ago
Yes - I don't hate it. ...which is literally the highest praise I have ever given and probably ever will to issue-management software. They correctly realize that we mainly want to not notice the software, which is something that every competitor gets wrong. What I can't figure out is how they possibly got funding in the reddest of red oceans with a pitch that couldn't have been much more than "we'll make Jira but not suck" (that's essentially all it is), but I'm glad they did.

dmos62 3y ago

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%.

adastra22 3y ago
Sounds like the GTD approach. Works well for me too!

jjk166 3y ago

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.

esafak 3y ago

They had to call it an "Ask" :(

marginatum 3y ago

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.