I do find that reality is hard, though. There's always that moment when you don't feel like picking "the one at the top". Maybe because you have time for "a quicky" maybe because after spending a week on Foo, you now want some Bar?
What this also does not solve is the "panic shifting". When a business goes into panic mode (deadlines, rough patch, downtime, chaos) you'll often see that tickets get moved from underneath you while working at them.
- Holdit, I'm done 80% with that SuperImportantEmergencyBugfix. Can I not finish and deploy it? - No, there now is a SuperEvenMoreImportantEmergencyBugfix that has to be fixed two hours ago.
No ticket system will fix that, but anything that helps with those moments is very helpfull, I guess.
If everything is urgent, nothing is urgent. Even in an early-state startup, where urgency abounds, it's possible to work with a measured pace and clear focus. I've done it! https://williampietri.com/writing/2015/the-big-board/
The fact that larger, more stable companies fail to create order is not because it's impossible. It's because the people with power either don't care or have interests that actually work against getting things done quickly and reliably.
This is what I have seen, time and time again. Decision makers don't work for their employer, they work for their compensation package. It's amazing what one can rationalize when one thinks it might positively impact some number that's mechanically tied to one's bonus.
I've also seen it arise as a simple "too many cooks in the kitchen" situation. Ironically, the one thing from Scrum that I like without reservation is also the first one to get thrown out the window: the idea that exactly one person gets to decide the development team's priorities. Because if you allow n people to collaboratively allocate a scarce resource, they will allocate it to n * 100%, every single time.
Equally predictable was the later addition of P0. Followed inevitably by P-1. Sadly the company was bought out before we learnt whether the underlying datatype was a signed short or a long...
The somewhat untold benefit of this system, is it makes the product manager or client decide between "I want to control this ticket" and "This needs to be done as fast as possible". That seems to naturally filter out tickets that are only superfluously high priority.
Basically all tickets would naturally migrate to P4. Eventually when someone started working on 'the wrong thing' another level was added.
In my current job we use Jira and the backlog has things at the bottom which have been just added, things at the top which we thought were priorities at some point and a whole bunch of crap in the middle which is unordered.
I keep thinking about some kind of system where people would rate the priority of one ticket against each other rather than against an arbitrary scale.
Everything is prioritisation. I'd say that prioritisation is one for the key skill of people leading organisations.
People who can't do it will fail whatever tools they use.
The "top ticket first" approach forced us to improve knowledge sharing in the team. In practice, you can pick the second topmost ticket if it doesn't affect the schedule. You're a grown up.
The tickets you work on should not be based on your feelings, but on actual priority. In practice, if you feel like it won't affect the schedule, go for it. You're a grown up.
In my experience, panic shifting is more manageable with Kanban. Tickets aren't given arbitrary deadlines, so shifting them around doesn't change the order of work, but not the intensity of work. Bringing one ticket up pushes every other ticket down. Nothing gets squeezed into the sprint.
As for interruptions, it's a matter of urgency. Usually, Kanban dictates what you do next, not right now. There's also a limit on how many tickets you can have in progress. In practice, it's up to you to decide if a task is urgent enough to interrupt your work. You're a grown up.
It's also not compatible with complicated work. If you're still in the discovery phase, sometimes it takes a significant amount of work to get to a point where you really feel confident on what the end goal looks like, and how to estimate how you'll get there. In that case the work is shifting under you too much for Kanban to be of much help.
For instance, your “panic mode” is discussed in The Goal (as “factories that seem to have three priority levels: Hot, Red Hot, and Do It NOW!!!”) and the emergence of those panic modes is actually diagnosed as a failure of those first principles. If you had managed differently, you would have been aware of your spare capacity, and this panic mode instead becomes a business problem of some sort—either you are not getting enough biz value out of your “SuperImportantEmergencyBugfix” project to justify continued investment of developer time or you are not getting enough biz value out of the EvenMoreImportant project or else you are getting enough business value out of both that it is time to expand your dev team so that your bottom line can get better sooner. But rather the panic is usually because the two projects are not profitable either way, and the company was willing to take a loss to build them up to profitability, but now revenues have gotten unexpectedly tighter and people are trying to fallaciously optimize on cost rather than marginal profit.
"people are trying to fallaciously optimize on cost rather than marginal profit."
Pure truth.
Another great book is The Principles of Product Development Flow: Second Generation Lean Product Development
https://itrevolution.com/book/the-phoenix-project/
https://itrevolution.com/wp-content/uploads/files/PhoenixPro...
And Commitment is about software projects, and is a graphic novel (with a female protagonist!):
https://hennyportman.wordpress.com/2016/05/29/review-commitm...
I'm also reminded a bit of Simon Wardley's dialogues with X; these are just a roundabout way of him expressing his thoughts, but because they're structured as a debate, i think he gives himself a bit of unearned authority when he runs rings around his imaginary opponent:
If you are judging any dimension, say priority, then assigning percentile rating to a task (i.e where does this given task stand relative to all the others) can be quite helpful to overcome the "SuperEvenMoreImportantEmergencyBugfix" cases. This is what the article is also suggesting.
And if you end up assigning 90% percentile to more than 50% of the tasks, you know your judgement is wrong, and it can be corrected accordingly. And it can also be standardized much better across the organization. Everyone can now judge their own judgements.
Rating on multiple dimensions with low correlations important for your company, say signup rate, retention, security, etc. and adding them up is a good way to not miss something important. It's not important to assign weights. Equal weights is fine [2]
I'm finding this technique quite useful in deciding what to work on next with fewer doubts about their priority. I failed to make Trello work for this and use a spreadsheet.
[1] A Structured Approach to Strategic Decisions - https://omegaleadership.com/media/Structured_Approach_to_Str...
[2] The robust beauty of improper linear models in decision making. - https://pdfs.semanticscholar.org/8793/408a67fd4c32bd7b5483d3...
If you are in an environment like this though, try to do very atomic commits as you go. Often you can salvage some work for the betterment of the platform even if the whole feature is not needed. Maybe you did some refactoring, if that's in a neatly organised commit you can just cherry pick it right out of there.
An extra case of all of the above is planning work around big releases and the like. Regardless of how solid your CI pipeline is, if there's a bigger change set released, it's good to have someone who's designated on call. They're free to work on their stuff if they please, but their main priority for that whole day is the delivery. If anything is fishy, they're the guy who picks it up first.
None of the above happens without good communication. To get to good procedures you need to take the time, discuss with your team, and agree on what your plan of operation is. Make sure it's clearly communicated both inwards and outwards. If anyone internal or external comes to you with a fire, you can point them to your plan. It may be urgent to them, but that doesn't mean it overrides your team's agreements.
With all of the above in place, the scenario you described changes considerably: instead of asking whether you can finish your task, you will instead inform the other side that you're going to finish your task, and if it fits your plan, then deal with their problem. At the end of the day, it's a matter of mutual respect — it doesn't matter what the org hierarchy is, they're asking you for help, they can't demand it.
By all means, try to change the system, but telling others they should too is advice from an extremely privileged position.
A few solutions for this that have worked for me:
* Small units of work
* Having a tech-debt backlog broken into short lumps of cleanup, so you can "take a break" with something different
* Pair programming with frequent pair rotation. The next ticket is always taken by the next open pair, but you can work one something different every few hours if you need.
* trade tasks with a colleague
* sighing, saying, "well, this is my job," and picking the top thing anyhow
Although I would agree that if you have to reshift on hourly basis, this sounds more like oncall than normal dev work :)
Agreed on "on the top" not always being viable / feeling like it, but it helps when you go top-to-bottom consciously as opposed to randomly.
But, it occurs to me that this has always been a seller's market. I have, in my naive youth, thought, "What are they going to do, fire me?" Because they might, but it's not like I couldn't another job -- probably even higher paying! What exactly is the "means of production"? Is it really the capital that pays the salary of the programmer, or... is it the will of the programmer to actually write the code? By and large, the programmer is very difficult to replace. If you take note of the incredible number of programmers that are an absolute PITA (I mean, I'm sorry but we are and ornery bunch!), how on earth do they get jobs if the capitalists are not completely desperate. In fact, the big companies even lobby the government to allow them to ship programmers in in large quantities!
So can you not finish and deploy it? I wonder... What could possibly happen?
Small print: Not responsible for loss of livelihood, and social shame that results thereby.
However, the big difference to people not handling the ticket (the customer/business + the person(s) who have to deal with bug accountability) - a bug usually represents a failed promise and is quite different from a feature.
If I go to a restaurant and there is a "bug" in my order, I expect it fixed for free, so that in the end I'm getting my original order (with the extra work/time requirement eaten by the side which erred to begin).
If I want to change my order because I don't like the food after all, then that's not a bug, that's a change in requirement/feature request.
Having bucketed priorities (highest/high/medium/low/lowest) is a big failure of Jira / ticketing systems though. They should be a unique set of priorities, with only one single ticket occupying #1 priority, another slightly less one in slot #2 etc.
Jira supports both. The thing you're describing is called Rank and is used on every board and backlog. Our team uses Rank almost exclusively. The bigger thing to understand here is that different people use different "labeling systems". If you ignore software dev and think about note taking, there are a bunch of different systems. Some work better for one group of people, others work better for another group. I think Jira has had a lot of success because it doesn't force people into one system. The downside is that people often configure it to use 3 different systems at the same time and they vary team to team and this causes a lot of strife and confusion.
I don't see really see anyone stating obvious truths about bad developers & software engineers (as shocking as it may be to read on HN that there are, in fact, objectively bad developers & software engineers with high-paying jobs at companies whose names you know.)
- they are more interested in making a new thing instead of fixing a broken thing they released
- they often can't remember how they built the last new thing
- that's because they aren't interested in building & documenting a fully working thing with test code from the start
- they aren't interested in data structures or architecture built to be easily maintained or in making scale part of their designs
- they despise being told to fix bugs because it is much easier to write code than it is to read it
I believe some organizations implement Jira thinking it is going to solve their cultural problems. This is magical thinking.
I am so tired of hearing about how terrible Jira is from developers.
It's usually the case that where Jira isn't working it has to do with the way it's configured (e.g., giving too many people access to set priority, setting too many priorities, setting too many components, using components in illogical ways, no one actively managing & grooming queues...)
To implement Jira successfully probably requires more work & effort to get it right than to not use it at all. The point of it is not to eliminate the work of issue tracking. It is to organize the workflow management of moving incredibly complex information from one person to the next. It's pretty great at this if you know how to use it.
If I order a Lasagne and get spaghetti meatballs, i think that's a big and i expect to be fixed.
If I order Lasagne and get Beef Lasagne when Inamna vegetarian then I still think it's a big, but the failure is not immediately in the kitchen - why did the waiter not check, if I am wearing dungarees and a a Tee Shirt saying "Die all meat eaters" should that be a clue?
And what about the kitchen response - we all like the restaurant that apologises and comps the food for free. But we would be a bit surprised if we were told the Beef Lasagane was not going to be refunded and we had to pay again to get the veggie one.
But all those models exist in software.
Arguing that it's not a bug seems like saying 'not my problem' to everyone else. I expect different companies have different cultures around assigning blame that might make saying 'not my fault' important, but I'm pretty sure that customers/users don't care one bit about that.
Oh no.... You are wasting yours and theirs time. This is such a developer thing to do.
If the waiter gets the request wrong from the customer, it's still a bug. Even if the kitchen does exactly what was in the waiter request.
It's a team effort.
There are obvious cases where I have nothing against what you say. But to use the analogies, "I thought the food would take differently and I don't like this one" is the more common type and it's the one that's murky to resolve.
The point here is that regardless of the reason, you want to tend to "customer is not happy" case.
If I'm going to do a big refactoring of some component, I find it useful to look for related open bugs (even if they're low severity) because sometimes it's low or zero extra effort to fix them at the same time. This only works if you have good quality tickets though (proper tags, alias words, etc), which is a whole different topic.
I think it also reduces cognitive load while looking at tickets to have them categorized that way too. Of nothing else being visually distinct (via icon or something) just makes it easier to process.
Above all though, it's important not to argue about bug vs feature. Ideally any bug can link to the feature ticket that isn't working, but either way it's more important to make things better for the customer, so if that means considering a what is really a feature request a "bug" because it'll cause a big argument otherwise, then do that.
I've heard the ability to drag & drop tasks around in an ordered list (i.e. a task only has priority relative to others, i.e. it's position in the list) as "ordinal priority".
Where I think it _does_ matter, is when a business wants to track metrics like "# of bugs over time" or "# of bugs per feature".
My team recently got a lot of heat about "a rising number of bugs", and the insinuation was that our code quality was poor. Turns out, > 75% of the "bugs" reported were mis-labeled feature requests or lack of knowledge about how a particular feature was designed to work.
There's so many ways to influence number of bugs that it's pointless to measure anything that way. For example, do you make a single bug that lists 15 typos spread around, or 15 bugs (because after all, each typo is a different word and in a different part of the app). Do you accept vague but obviously real bugs while you try to collect enough info over time, or immediately close them as "cannot reproduce"? Is that a bug, or really a feature request?
Oh, you want to make a bug ticket in my project? In that case, required fields include "steps to reproduce", "expected result", and "actual result". You want to make a feature ticket in my project? In that case, required fields include "rationale" and "acceptance criteria".
For example, if you have a word processor, having a running word count sounds like a feature.
To a developer it seems frivolous, like having a LOC counter.
But to people who write professionally word count might be the most critical metric of all (like a progress bar for "article is done")
just saying... failed promises
A ticket type makes sense because bugs and new features are not the same and we should care about the difference. A bug is a defect in the implementation of a feature that should be fixed. A good practice is to fix defects before adding new features, as far as possible. A defect is discovered on a specific software version so it then makes sense to indicate that. Even with continuous delivery it is useful to know exactly what build exhibited the issue. Having explicit information on whether a ticket is a defect or a new features is also helpful for QA (as is severity): I need to keep track of the number of defects found in order to somehow measure the quality of my software and of my testing and to improve it.
Assigning a priority makes sense because it helps setting the ticket's position in a queue (which can be called TODO list).
Severity is not the same as priority. Severity is the impact of a defect. A defect that causes the application to crash and delete all data is very severe. A typo is likely not a severe defect. Again that helps in assigning a priority and thus how to insert the ticket in the TODO list.
The position in the TODO list is not an input it is an output of the task that consists in analysing and managing the pending tickets.
You could say that a dev is a worker task that picks the next ticket in the TODO list in a loop, while a (project) manager manages the tickets and insert them in the TODO list.
> A good practice is to fix defects before adding new features, as far as possible
This is the approach I describe as "bug is a proxy for priority", where you are essentially saying it's "highest". It is a good approach in theory, but just ignores business realities.
It also means people will try to disguise feature requests as bugs in order to get a priority.
> Assigning a priority makes sense because it helps setting the ticket's position in a queue
Except if it's numerical, then over time, you can safely ignore everything that's not P1 and you have few dozens/hundreds of unprioritized tickets.
> Severity is not the same as priority.
I know. Why is it important to make the distinction though?
> The position in the TODO list is not an input it is an output of the task that consists in analysing and managing the pending tickets.
Agreed.
> You could say that a dev is a worker task that picks the next ticket in the TODO list in a loop, while a (project) manager manages the tickets and insert them in the TODO list.
Well, if dev is a factory worker turning inbound tickets into outbound features, yeah, cool, this works.
I am yet to see this in practice. Team (or at least team lead) is taking active role in the managing cycle and this is exactly what renders a lot of your points at least duplicit.
(But you have a lot of good points about assumptions about team organization that should be mentioned)
If my car breaks and cannot start, that's a bug. If I want to add a radio to my car, that is an extra feature. The difference exists, and it is important. You are saying this difference should be ignored because someone may try to pass the desire for a radio as a broken car. At that point, you could just ignore any issue because it may be a lie.
And the reason to categorize is not only to prioritize. For example, we have these rules: bugs require of a test case, and the test must pass to consider close the bug. On the other hand, new features are implemented first in a different tree, and the new feature needs to be documented (also in the tutorial). Moreover, we may have meetings to decide if we add a feature or not (for example, different new features may not work well together or may require extensive refactoring that we do not want to do), while a bug must be fixed.
In your workflow, this distinction may not be important. That's perfectly possible. But, in my opinion, claiming that "we collectively shouldn't care" is going to far (unless "we collectively" means something more specific than it looks to me).
A bug is not a proxy for priority. As said it is a parameter that helps defining a priority and, in fine, the position in the TODO list. Whether priority is "high", or P1, or whatever is exactly the same. Usually there no need for too many levels because, as you suggest, it mostly boils down to "now", "afterwards", "whenever", and that changes over time (hence Agile ideas).
BTW, I have never seen someone disguising a feature request as a bug. That is totally unrealistic not least because obviously this is continuously scrutinised and someone doing that would be called out and ultimately fired for shear incompetence (or worse) and because features go through a definition process, it's not someone who suddenly dreams one up and sneakily hide it in a bug report to have it implemented without anyone noticing (what?!)
The distinction between severity and priority is important. Severity is assigned by the person who reports a defect. It is a measure of how serious the impact of the defect is, as said. Priority cannot be set at that point, as it is a judgement made later based on further considerations.
Devs really are as I described in teams that have matured and are organised (but maybe not in "messier" startups). A team lead is not a dev, 'lead' implies a managerial aspect.
Lastly, of course you need to keep track of the number of defects (which can be from customers feedback and production metrics) and of their severity. This is basic QA, you have to know if you are effectively doing a good job in order to improve both your internal processes and the quality of your product.
For example, if I start to see too many critical defects on a component/team I know we have a problem there. If I start to see too many critical defects found after the product has shipped I know we have a big problem.
About the only thing I might add is dependencies. But even that is mostly value for management reporting and time estimation. It doesn't help the workers do their jobs that much.
I would love if you could expand on that. Do you really need it? Is this more important than production metrics or customer feedback?
Work tracking isn't just about figuring out what work needs to get done, it's about helping management get a picture for the state of work.
Developers and other line workers don't care about obsolete vs won't do. But management does. They want to know if they're being requested for work that will be rendered useless in a few weeks. They want to know if too much work isn't getting done because work is floating up to the CEO and it's not worth his time.
There's a terrible principal agent problem here where management, the principal, decides how to track work, and can put the heavy lifting of filling in values onto the developers. This happens when management's more worried about losing their job than improving their team's output.
Say there's a billing system. One of the accounts receivable clerks notices that due dates aren't properly adjusted for public holidays. As a developer, do you know how big a deal that is? Probably not. Doesn't sound like a big deal. But maybe it means we're imposing penalty charges on customers where we shouldn't be, and that's a huge legal and reputational risk. Or maybe it really isn't a big deal! The boss will need to have a conversation with the clerk to learn all this, but maybe having a severity field is an ice-breaker for that conversation.
The only problems in your scenario arise from the introduction of a boss as go-between.
I no longer believe a single tool is good for both a team tracking & communicating amongst themselves about the work they're doing, and communicating the same to and among management. Trying to make them both the same thing is a great way to come up with something that's terrible for one or the other of those uses (usually the former).
Yet I refuse to do it to them, the ICs.
We tried Jira but became tangled in a mess of complex configuration and endless confusing UI's...
I agree this is sometimes true, those difficult to reproduce tickets often mysteriously disappear when you make other changes. But there are lots of times when a lot of work has gone into creating the ticket so there is actually not much left to do to fix the issue. In this case closing tickets that get too old would be very counter-productive.
Suppose that someone tries to check, but the bug doesn't reproduce in 1.2. However, it was never root-caused. All we have is a description of the behavior that was happening in 0.5.
Now what? Do you just close that bug to get the open bug count down?
Probably an "unsolved mysteries" or "cold cases" category would be more appropriate for it rather than lumping it with genuinely closed bugs: those that were traced to a root-cause and confirmed.
In cases when you're sure that the bug was due to some software that was entirely rewritten such that the same bug cannot plausibly be in the rewritten version, or some software that was removed entirely, then there is justification in closing that.
The TODO column is an ordered list of things to do. The job of the developer is to pick tasks from the top and move them towards the right. The task of management is to keep the TODO column sorted, and prevent tickets from being stuck in any other column.
The task of management is aided by limits on how many items each column contains. Those limits are based on how many things people can realistically do at once.
In theory this would work, but it has the pre-requisite that whomever is managing tickets understands technology - which, in my 10 years in the field, has been quite rare.
In my experience, it's usually done in a weekly meeting that involves a small subset of the team. We don't need to estimate tasks. We only need to know their logical order (dependencies) and priority (requirements). We don't need the whole team present for that.
If the requirements or reality change during the week, there is no cost to reordering the todo column. It doesn't change how much gets done, just in which order it gets done.
And that affects prioritization a lot.
> - If there is downtime, it’s the top priority of everyone affected
> - If there is an incident, it’s the top priority for an on-call agent
> ...
Very much agree about this.
The trouble with "high priority" and "low priority" etc. is that different people perceive different things as having different urgency and importance. As long as you have >1 person entering tasks, each using their own algorithm to assign priority, a "sort by priority" (the only point in having a "priority" field at all as far as I can see) becomes completely useless.
If you use names like "downtime" or "incident" then, as the author writes, everyone can agree. That's the important thing I think. Then a "sort by priority" can yield something meaningful.
Plus there's the fact that when you have pages of "highest priority" tickets, managers just create all new tickets at that level, "otherwise they won't get seen and done" (true story)
This way of working annoyed me so much I wrote a blog post about it: https://www.databasesandlife.com/priorities/
But, as I mention in another comment, severity does not directly map to priority. Something like severity x frequency (classic measurement of risk) is already getting close, but ultimately it is often a judgement call based on other business considerations as well.
As far as I can see, consumers of tickets need to know what order to do stuff in, and producers and organizers and curators of tickets need to set what order things should be done in. That's "priority" or "urgency".
I do understand in a theoretical sense that "Prod system is down" might not always be the absolute highest priority thing to work on. If a particular issue causes a downtime of 1 second every 10 years, it's still downtime, but might not be the most urgent thing to work on.
But that's a theoretical example. In my 20 years of software development and managing projects, if the Prod system is down, it's an emergency, and that's what you need to be working on. So "Prod is down" is a useful priority/urgency. At least that's been my experience so far...
What am I missing? Are there times when priority and severity are useful as two separate fields?
Within a given severity I think its then a judgement call of a product owner to rack-and-stack the issues in priority order, exactly how it would be done for traditional 'P1' - 'P5' grading.
What I like about it, is that it enforces workflows (either scrum, kanban or simply one-large-backlog) The Way They Were meant. So it solves a lot of bikeshedding and solves me & my team from trying to invent "something that works for us".
The idea proposed by OP works quite well there too, with kanban. Just pick the card at top, and never have more than one card per working person in "active" at any time.
I've been working on a project that is attacking this problem but from the TODO comments angle. https://cosmolabs.io
Except it's that plus 1.5GB of memory use and a few tens of a % of a processor core.
[EDIT] and I've found that to be true when working for people so good at using the software that they made popular training videos for it, not just morons who don't know how they work.
Bugs in the bugs folder, with a text file for "reported", "active" and "fixed" bugs sorted by release version folders.
I honestly would want to try it. Files and folders are the abstraction that was supposed to replace physical folders with files, but in practice files stored in computers/network/mail are just a bunch of papers randomly put everywhere. How about using folders as they were supposed to ...
If you mean how they handle them, there is an incident procedure for that. If it's not really an incident but, well, I need this next week for Gartner Magic Quadrant...I have phone numbers of managers in my reporting chain.
If there are conflicts then it's up to the managers to fight it out.
* who reported the issue * what they reported happening * what they expected to happen instead
For many reported bugs, it is clear what the actual problem is and what needs to be done to resolve it. In this case, it can feel like unnecessary overhead to track the bug in a separate system from the rest of the development work queue.
But it's worthwhile to have a place to track bug reports that can't yet be acted on by writing code. Sometimes it's not immediately clear what is happening or what should be done about it. Sometimes you need to reach out to the reporter(s) for more information or to let them know progress has been made.
Even with well-understood bugs, there can be a many-to-many relationship between the bug and the development work to be done. Sometimes you have many people reporting the same issue in different ways, and it's not initially clear that there's a shared root cause. Sometimes one bug report is best addressed in multiple phases of development work.
I'd argue that there's always someone who's managing all of the above, even if they're not using separate bug tracking software to formally do so. But as a team grows, making the investment to "show your work" a little more can make it a lot easier to collaborate and delegate.
* I am not sure "who reported the issue" is actually important, but rather "who is the contact person to get more information about this issue" and "who should be informed when this is done for verification", where "verification" means "satisfies expectations now" (as opposed to QA meaning of the word)
* Reported happening/expectation is a good point for any expectation mismatch report. I am not sure it should be there for all issues though as I find it can decrease clarity in the same way artificially requiring the "As X, I need to do Y in order to achieve Z" does
If you're forced to describe what happened and what you expected to happen it makes it very clear when those expectations do not align with those of the people designing or implementing it.
And remember, most (all?) software projects are not defined in a singularity. They evolve. As users use the product, the understanding of what you built changes. There is no ability to define a project of any significant size in a box the first time. We aren't pulling rabbits from a hat.
You can also simply keep track by keeping tabs on the work you are doing, which also leads to a better product as you're familiar with what the product does rather than simply knowing that X, Y, and Z issues are closed.
Non-technical stakeholders will not be able to follow it that way, having their focus on other important parts of the business, but that's why you have project managers who can follow what the technical side is doing and provide the necessary non-technical communication to them.
Ultimately, you're both right. There is just some conflation going on. What is useful for some segments of an organization does not make it useful for everyone.
I agree that ultimately (and quickly) the bug needs to land with a single person, but the component matters in the routing step before that. Because you'll have frontline triage who can only vaguely figure out where the bug goes, second-line triage might get the team right, and then the team needs to decide where it goes.
Yes, that's a lot of overhead. Unless you have 1000+ people working on your software, you won't need it. Up to ~100 people, you can probably assign fairly directly, depending on the range of problems the code base spans.
Similarly, there are reasons why you don't want to do task breakdowns for everything in the bug tracker. Global refactorings are a good candidate to skip that, because you will do that across teams, piece by piece, and tracking them in a bug tracker is not necessary. We got spreadsheets for that ;)
Same goes for priority - sometimes you do need it. That zero-day you're fixing is a "drop everything else" bug. And really, the "flow" is just nine different priorities. (God, let me never work on something that has nine different priorities ;)
So, "season to taste". But there are definitely lots of good ideas in there. If there was just ONE I could enforce across all projects I ever work on, it'd be "Close the damn bugs if you're not going to work on it" - issue hygiene is incredibly important.
> I agree that ultimately (and quickly) the bug needs to land with a single person, but the component matters in the routing step before that. Because you'll have frontline triage who can only vaguely figure out where the bug goes, second-line triage might get the team right, and then the team needs to decide where it goes.
I do agree it's about routing. My problem with components is alignment with teams and their stability over time and survival of existing tickets across those changes, which is why I think different routing mechanisms are better. But yeah, if it works...
> Same goes for priority - sometimes you do need it. That zero-day you're fixing is a "drop everything else" bug.
I call those "an incident" and in every environment I've been at, everybody knew which one it is very well without any labels ;)
As for the priority label - it makes sense if there's either a huge bug load (cf. bug hygiene ;) or in environments where you have automated workflows. I.e filing a bug with P0 alerts the responsible engineer, starts a log document for the inevitable post mortem, lets production know, whatever you need to do for P0s.
Not all fields in the database are for humans :)
I have occasionally thought it'd be nice if we ditched a lot of UI & status fields, and the IC view in the bug database is just "what is the most important thing for me to work on right now". One issue. Only comment history, no other fields. You still need the rest for reporting, analysis, workflows, but as IC, that's what you care about.
Re: Position In a Queue
> Every team must have a single ordered queue of tasks > every single one of them is prioritized relatively
This may lead in Eisenhower's matrix to prioritize urgent tasks vs important tasks and end up with tech debt.
I lead a soft eng team and we have a task queue but they are not prioritized (and that may be a mistake). Beyond the time wasting agonizing if X > Y for tasks, I like to keep parallel tracks of urgent (blocking) and tech debt tickets.
Re: Ticket Type
The most or one of the most important metric in software is user angry or happy calls (a proxy for revenue). If an unannounced planned feature doesn't make it to the next release, nothing happens. But if the customer now sees a regression bug (something that worked suddenly doesn't) that's bad. There's value in differentiating bugs from features, at least in some industries.
Re: Software Version
See Semantic Versioning https://semver.org/ ; it's important to know if a release is backwards-compatible or not
An angry phone call doesn't universally change the order of work for all companies. Some projects might rate this event more importantly than other projects. Most angry phone calls are a result of usability problems not strictly feature defects. So there's no direct correlation here between user product sentiment and backlog priorities, unless your company culture adds that correlation.
> why do you want to have this information and what is it going to be used for?
You might say this is yet another proxy for priority, but it's slightly more nuanced than that. A lot of software companies do not have the experience of continuously deploying the main code branch. I work on a SaaS solution that's gained traction in highly regulated industries.
It's very useful to be able to identify (trends in!) bugs that could be described as a "regression" or breakage in behaviors that customers are known to rely on. This isn't the example of "Customers" from your post though, ultimately how the change gets prioritized and released is what they care about! This is about being able to identify and systemically manage change in high risk areas.
A missing feature can be just as onerous to a user as a defect. Understanding if an issue gets in the way of productivity is all that matters, regardless if it's described as a bug or a feature.
Tracking metrics against bug vs. feature is a surefire way for a system to be gamed. If there are consequences in finding/reporting defects, then all work-items will eventually be labeled as "features". Or if you reward finding bugs, then all work-items will gravitate towards "defects". It's up to you how you want to play this game.
What businesses want is a way to be able to track progress and communicate priority.
The difficulty for the the business is how they communicate their priority to you, that's what the priority field is for, it's a way for the person raising the issue to supply a way to communicate how important an issue is to you.
The position in the queue is how you (and presumably your team) should decide what order to tackle the work in.
The final point is the solution to the problem is to create another system for issues, which goes against the point that says "every team must have a single ordered queue of tasks".
I find it interesting that the solution to, in their own words, "One of my life’s traumas" is to add another issue tracking tool.
Are we trying to fix the right problem?
How do you propose that queue is prioritised and consumed by the development team?
When people say things like this I often wonder if they worked with a more consistent caliber of people than I have.
There are most definitely bugs, and figuring out that most of them come from a couple of people is critically important to saving the project in the long run.
Knowing that you have 5 bugs and I have 7 is, I will agree, not important. But knowing that Steve has 50? Is really fucking important.
article {hyphens: auto;}Just be thoughtful about how you do this otherwise it can easily come across like "we don't really care about your issue".
Google has had two rounds of auto-closing old Android bugs and their message is really bad. Something like "Our product team is prioritising other things.".
Similarly Github's stale bot is way over used. One project I submitted a bug to closed it because there was no activity for only a month.
If you must close old bugs automatically, word it nicely, and don't close it instantly and ask people to reopen it. Something like this is best:
> We're trying to clean up our bug tracker. This bug is older than 5 years and has had no activity for 2 years. Is this still an issue?
Compare with Google's message:
> Thank you for your feedback. We have tried our best to address the issue reported [they hadn't], however our product team has shifted work priority which doesn't include this issue [what does that even mean?]. For now, we will be closing the issue as "Won't Fix (Obsolete)" [great, thanks]. If this issue still currently exists, we request that you log a new issue along with the latest bug report here: https://goo.gl/TbMiIO and reference this bug for context.
Let’s say the author is right and ticket queues should be a single stack with no priority. That seems pretty easy to make. Easy enough on a popular enough topic that I’m sure it’s been done. But, I’ve never seen or even heard of one in use. Why? Because it forces people to make hard choices. The software doesn’t handle all the real world crap that comes up when people try to use it. It can’t make the jump out of the local maximum. So instead, we get people endlessly iterating on the same ideas and releasing the same basic project trackers with slight twists.
Also, I think there’s a billion dollar company for someone who can make an internal support tool that people will actually use.
It works to an extent, but then someone somewhere usually has an abstracted concept of priority, otherwise you end up with priority as per the "highest paid person's opinion".
One difference I had from the article is that I actually find marking tickets with priority and types (like bug / enhancement etc) useful, but for a different audience.
When I’m working on planning / strategy, aka in Product Manager mode, I like to be able to review what is still remaining in different buckets and adjust priority and do scenario planning. Maybe it’s worth closing a whole bunch of low priority bugs before moving on. Often the priority changes over time and gets adjusted as we see what came in. Having a place to track that info on the ticket keeps me from moving to doing planning in a spreadsheet.
When I’m in developer mode, I agree - I don’t want to have to think about what the priority of a critical feature improvement is vs a low priority bug. I want to pick off the top of the stack and flow with confidence.
I often am working in both roles on team projects and use this technique even when working alone.
In my experience where things get weird is when the product planning metadata is required to be understood in real-time by all roles on the team. You can keep all that metadata around and still have a single prioritized backlog.
Maybe Jira could be improved by showing different metadata for different modes... but even writing that out sounds like a new configuration nightmare!
Ugh, RedHat bugzilla trauma is coming back to me. Report issue -> 12 months nothing -> bug closed because new RedHat linux version was released. Repeat.
As a user, it's extremely relevant to me. I paid for your product/service because of what it claimed to do. Bugs are ways in which it doesn't do that. (It doesn't matter to me if some other hypothetical features don't exist yet, because I was happy to pay for the product/service knowing it didn't have those features.) As far as I'm concerned, a bug is your company not holding up your end of the bargain, even though I've held up my end by paying for it. That's not a good look.
Another way to look at it is that a bug is downtime for a feature. Elsewhere, you say (system) downtime should be #1, "top priority of everyone" until it's fixed. But what good is the system being 'up' if it's still broken in the way that I need? When I lose power at home, it's no consolation to hear "The power grid as a whole is still up -- it's just your neighborhood that's not working", nor would I consider this reasonable justification for de-prioritizing fixing it.
Maybe your company is at the stage where attracting new users with features is more important than keeping existing customers with quality. But they say it's always easier to keep customers than it is to acquire new ones, and I've blackballed several companies because they no longer place the priority on quality that they once did. You should be aware of what you're giving up by de-prioritizing 'bugs', or pretending they don't exist. I see comments here on HN every day complaining about specific companies whose software quality suffers. It takes years to dig yourself out of that hole.
The suggestion I put out at an old company (which was shot down) was the idea of owning features. If all the bugs for features you own are resolved, pull a new feature. You now own the bugs for it.
It gets difficult when a feature is too big for one person, or too important for that developers bugs to be a blocker.
There should be an Introduced-in Version and Fixed-in Version.
“then ‘upkeep’ and ‘new’ should be the ticket types”
Is "Make app work on device X" or "Add cornercase Y" new or upkeep?
That doesn't work in teams with collective code ownership, ie all successful teams. But you can replace this with "assign to a single team" and i think it works much the same. The footnote to this says:
> For larger teams, that can be a team account, but in that case, it is team leader responsibility to go through all team owned tickets regularly and delegate them
But that isn't correct. You can have a team pull from a single queue of tasks assigned to the team as a whole. There's no need to proactively assign them to individual team members.
> Every team must have a single ordered queue of tasks.
As long as you understand that "tasks" does not encompass technical housekeeping tasks like refactoring, improving the test pipeline, etc, sure. The queue of tasks needs to be ordered by someone with customer/business/domain knowledge. There's a negligible probability that this person is also expert enough to prioritise housekeeping against feature work. But the development team itself can do that, no problem.
> I advise to start with the “Todo”, “Doing” and “Done” triad and only add more if absolutely required
This sounds good. My one thought is that there are usually different people who can say "i think this is done" (the development team) and "yes, this is done" (product owner / QA / etc), so i suspect todo/doing/ready/accepted as the minimal set. But you could find a way to make three states work, i'm sure.
> When people scream “this is a bug”, it is irrelevant what it is caused by
It's relevant to estimating velocity. If over a quarter, you estimated you'd do a hundred features, but actually did one feature and ninety-nine bugs, you should not plan to deliver a hundred features next quarter.
It's relevant to continuous improvement. If you're getting a lot of feature requests, great, carry on. If you're getting a lot of bug reports, not so great, slow down and see how you can improve.
> Saying “no” is hard, but without it, the issue system becomes an unmanageable mess.
We must recognise this as simply being an expression of the author's deletionist aesthetic preference, not a fact about the world. As long as you know what the most important tasks are, it doesn't matter if there are an infinite number of less important tasks behind them.
> Yet I do believe this is actually a property of any job position: people rarely want their job to disappear. The moment you create a job position, it tends to metastasize.
Very strong truth! My third (?) law is that if you hire someone to do something, then that thing will get done regardless of whether it is actually useful. I am most often reminded of this law when dealing with security people.
Agreed. My point was more about that there has to be a single person responsible for making sure there are no leftovers.
> But the development team itself can do that, no problem.
Yup. To the domain point, I do think that collaboration on that boundary is needed.
> It's relevant to estimating velocity (...)
Fair, if you only define velocity as adding features and if you automatically prioritize bugs.
> We must recognise this as simply being an expression of the author's deletionist aesthetic preference, not a fact about the world.
I think this doesn't hold over long term. It is true as long as you do have an idea what's in the rest of the pile. But the moment you change the person responsible for managing the tickets and suddenly they have thousand tickets to go through and orient themselves in, it matters. And if they don't go through all of them, they don't actually do the prioritization against each other.
The important thing to realize is that pivotal tracker is not a "bug tracker" in the traditional sense - a giant database where issues go to be forgotten until someone clears them out in batch three years later. In the Pivotal process there is a product manager whose primary responsibility is curating the backlog. There are no priorities, just position in the backlog. The PM should know what's in there, that's their job - they don't write code.
Engineers just grab stories off the top of the backlog.
Overall, I'm mostly aligned but it seems to me that it's very focused on low level product delivery. I feel like it's ignoring the bigger picture of how these "tasks" come to life and where they go after they're shipped.
Shipping software is much broader than moving tasks from "to do" to "deployed". If that was it, then yes, all you need is a flat & ordered list of tasks with an assignee for each. But it's not:
-How do you decide what do build in the first place? How do you make sure you are working on what's most meaningful?
-When you've prioritized the right problems to solve, how do you collaborate to come up with the right UX?
-How do you perform user research and user testing to validate your assumptions?
-How do you handle the feedback inbound you receive from stakeholders and customers? How do you take these inputs into account in your prioritization process? How do you then complete the feedback loop?
-How do you work with customer success and marketing to ensure everyone is informed of what you've shipped?
-How do you balance demonstrating product velocity while working on meaningful projects that take several weeks or months to ship?
What I'm saying is there is a broader context to shipping software beyond "accessing a prioritized list of tasks and getting them done". It's good to climb fast but if you're climbing the wrong wall, you're just getting to the wrong place faster.
That's the reason why my co-founder and I built Cycle (https://cycle.app/) – an all-in-one tool that helps engineers, designers, and product people to better collaborate in the process of shipping good stuff.
Does that marketing website typo fix need to go through the development team and require a ticket? There are reasons it might, but fixes will never really be fast enough if it does.
Or worse, what if a developer has to ask someone to create a task and add it to the board to add documentation to a method? Then either no will ever document anything, or they'll sneak those changes into other tasks, slowing down code review and feature development.
One way you can create those pathologies is to have auditors, and promise the that "all code changes follow a process" and soon you're signing forms in triplicate to make any kind of change whatsoever.
I have had quite a bit of success in having the technical teams assess the length of time a fix or a feature takes to do, but letting the stakeholders determine the relative priority.
I have seen requests and suggestions go from completely critical when requested, but when estimated at a couple of work then broken down into multiple much easier and clearer tasks when the stakeholders are included in the prioritisation discussion.
My experience is that stakeholders much prefer having things turned around quickly and they will what they can to optimise for things that are quickly and easily deliverable.
> Once you start assigning priorities from a list, anything else than “Highest” is a passive-aggressive way of saying “No”.
What can be gamed will be gamed. Once you start applying the equation "feature = good & defect = bad" or assigning arbitrary priorities "high, really high, now, yesterday", you are in effect providing opportunity to game the system.
Story points have this quality. More points are good, less points are bad. Let the games begin.
The value of a ticket / work-item comes strictly from the changes made to the underlying system. The "diff" effectively. The labels and types that we assign to work-items don't actually add any real value to the system.
It also includes pretty good PM tools like burn down charts, predicted velocity, etc.
This made me wish for a "git commit --future" that lets you just track future things to work on within git itself. "git stash" is kinda connected into this concept as well, branches too if used as development caches. It gets a bit wonky with multiple repos, as well as non-code related tasks, but then we have a single location for tickets, and a UI could be created to connect with other teams.
No. Every organisation. All the politics, all the empire building and compromises just to get along are brought into the fore and must be solved to decide if projectX is above or below projectY.
Do that, and we might just believe you are a company worth working for.
A FIXME cannot be in master, but TODO's all the time.