The only system that I appreciate is taiga. It's extremely opinionated and quite un-configurable.
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 appreciate how clearly it is written down. It is how I would like to work and have tried at numerous jobs.
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.
Our company became determined to control such panic-driven prioritisation, and had four simple levels of importance, P4 up to P1, a predictable conveyor belt delivering work.
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...
I've seen good success with having an entirely different pipeline for rushed/rapid/panic tickets. The rapid pipeline reduces some of the ticket and procedural bureaucracy of the normal pipeline, and only lasts a sprint. That obviously comes with risk, so putting something in the rapid pipeline needs to be weighed properly.
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.
A standard ticket pipeline might look like this:
Backlog > Review/Estimate > In Progress > Internal Review > Testing > Client Review > Feedback > Testing > Release
But the rapid pipeline will be more like:
Create Ticket > In Progress > Testing > Release
This leaves the ball almost entirely in the developers court, and removes any step that requires waiting for feedback from the client or even the Project Manager.
So you can see the risk factors pretty quickly, with no review steps what if the developer gets it wrong? So that leaves the Project Manager some important questions: Is this ticket concise enough to be rapid? No room for back and forth discussions or muddy details. Is this ticket small enough to be rapid? Can't be a big new feature that's just being framed as urgent but could realistically wait. Can I trust the developer to get this right with no review? If you can't, then it's probably best it goes through the standard pipeline with the review steps anyway.
In big enough teams it can help manage workload, you can leave a specific developer intentionally under-utilized so that they have space for rapid tickets. During their under-utilized time they can be open for mentorship/learning/pair-programming until a rapid ticket pops up.
That is so familiar that I seriously wondered if we had crossed paths at a previous job. The only difference being our priority was the other way around P4 being the highest.
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.
That’s the whole point of that backlog. The order should reflect the priority of everything relative to everything else. You drag stuff up above other stuff that is lower priority and part of everyone’s job is to groom that list so it reflects reality.
While that may be true in theory in practice it is difficult. A big improvement would be if new things needed to be inserted into the backlog at an appropriate place but I don't know if it's possible to do that in Jira.
This, I think, is exactly why everyone I know who is happy with their backlog management does it in an Excel spreadsheet or Google Sheets.
I'm fine with ticketing systems for handling immediate work in progress. Which, incidentally, is what they're meant to be used for. Every time I've ever seen people try to juggle business priorities and long-term goals in a ticketing system, though, the end result has always struck me as being something of a failed experiment to develop a product that works well as both an ice cream topping and an engine lubricant.
That ticket comparison idea is awesome. You could have it for one person, or do it democratically.
I bet there'd be circular comparisons (A>B>C>A) a surprising amount of the time. Not a huge deal, you could just show the pairings back again in a different order until they resolve.
I wrote a toy app when learning iOS that took the items in a todo list and showed you two at a time. You’d swipe the less important one off the screen. It built a hierarchy and you’d end up with the “most important” item to focus on. It remembered previous choices (or you could start over) to make finding the next item quickly, with just a few more choices.
It connected with the Reminders app and the Wunderlist API. I wonder if I could revive it with more services…
We've been doing that for a few years now. Basically we have two queues: The queue for escalated defects, and an ordered queue of about 10 prioritized enhancements that we've ordered based on what we think is most important comparatively. There is also a backlog of ideas/garbage work.
It works fine, except that the product is complex and old enough (and the team has too few developers so) that the bug queue rarely gets to zero.
This works well in theory, until managers urge you to treat every task as "P-0" and you suddenly need to prioritize within the P-0's (we would jokingly use negative numbers instead).
In my experience, the relative queue _is_ helping with that since you can be explicit. If SEMIEB is really more important than SIEB, it's fair to switch—but it should be done as a relative comparison / override. I mostly saw people pushing SEMIEB without being aware what they are pushing down.
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.
Priorities changing is one of the more frustrating parts of doing client work. Business priorities can change for so many different reasons, and you just have to learn to let go. I've seen entire product lines disappear the week a singular person leaves the company. Product in boxes, ready to ship, no longer needed.
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.
I think an important consideration is important for whom. If the only reason something is important is because of an arbitrary management deadline, the right response is to stand your ground and calmly finish working on what you already picked up. While I understand it's easier said than done, if you don't stand your ground, it won't get better. The polar opposite of this is when I personally broke something and it's stopping others from doing their work. In that case, the right response is to drop what I was or wanted to be working on and fix the issue.
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.
As an employee of the person telling you to drop your current work and go work on something else, it literally doesn't matter "for whom", you do it because you want to stay employed rather than doing "what's right" and getting fired over it. Standing your ground if you don't have solid seniority first is about as ridiculous advice as a parent telling their 7yo to "just tell them to stop" when they're getting bullied. You don't have ground to stand on, and even if your input is right, and well reasoned, it can't come _from you_ because your voice has no weight.
By all means, try to change the system, but telling others they should too is advice from an extremely privileged position.
First i do what my boss says, when i did that and we both have a little time to talk, i explain to him why i was thinking the other stuff was more important, often he has a good point from a complete different perspective than i have, sometimes i 'win' from my 'technical' perspective, after some time passes you learn to read each other and decision's are made without questions, for me its super important to know each others and the base where decision's are made.
Yeah, the best you can do at that point is to meticulously document your work. You don't want to look unproductive and get fired just because you're constantly stopped from releasing your work. And in the case that you do get fired, you will want to give your lawyer some ammunition in the form of work logs outside of the ticket system, which you will be barred from.
I sincerely disagree. Taking the extreme case you described as either do it or be fired, the other party wants a result, a task done or something similar, which still won't be done if they would fire you on the spot. It seems you misread my reasoning as blindly standing your ground which is not the case I was making. If there is a good reason to switch what you're working on, you should, as I also said above. But if there isn't one, you should either ask until you get a good reason or stand your ground.
The argument from privilege frankly confuses me. I've applied the same principles both when I've been the underdog and the one asking others and it's good guidance since it also gives you input whether you want to work where you currently are. Sometimes I've had harder times because of it, but I've never stayed in an abusive work relationship.
I remember when I had ~3 years of working experience. We were on the tail end of a fixed price/fixed date contract. There was a bug that needed to be fixed, and it was in a module that everybody had worked on, and the code was pretty bad.
So during the meeting, I said: that bug is just a sympthom, the module needs to be rewritten. And I knew what I was talking about.
No, said a senior, we're just going to fix the bug, no rewriting. I said that's your call, but I sure am not going to fix that bug. I can tell you: nobody listened to me.
So he more or less finished the discussion and said: I'm going to sit down with you, and we're going to fix that bug. And we did.
In that case there clearly is a good reason though? In the scenario described, you have one known bug, in the case of a rewrite you have an unknown number of bugs. Surely, both approaches may have more unnoticed bugs in them but in the former case people have already tested the solution so that's less likely. When you rewrite, you enter new untested territory with more room for new bugs.
Every junior and intermediate dev would like a word with that concept, because it sounds magical. Once you have a few years at an org under your belt, you have the creds to pipe up, but until then, you either talk with the better devs in private and hopefully convince them, or you do what your boss told you to do.
There's a great manufacturing-management book that regrettably speaks to a manufacturing context and not a project context and therefore applying it literally to our software projects would be a fallacy, called “The Goal”—and then the rederivation of the same principles for project management is in a follow-up book called “Critical Chain.”
They are both weird in that they are textbooks written as novels and therefore you do have to roll your eyes a little bit, of course when the beleaguered manager follows the smart scientist’s advice his company succeeds and his marriage gets better, sigh. And why is it a he, both times? But if you pay the cost of these eye rolls you get some joyous moments.
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.
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:
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.
For well-defined tasks, I love Kanban. Many people don't. But I think there is a lot of value in having a limited number of tickets "checked out" and having a quick, regular discussion on how the current state should be updated. It is also, in my opinion, the simplest way to "be agile".
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.
Time for a quicky is always good to have. When I don't however, I usually take that "annoying" task and see, whether I can divide into sub tasks. Divide and conquer often helps. If that does not work, I make a list of steps, which I need to take to accomplish whatever the task is about.
The panic shifting thing is real, and for me way too many companies operate in permanent panic. I'm fine with responding to actual crises. But so much "urgent" work is really just managerial failure. Fake deadlines used to "motivate" people. Broken processes that people work around. Executives urgently need to look like they're doing something. Easily solvable problems festering until they become crises. Managers rushing to score points, or to cover up for earlier neglect.
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.
> 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.
Agreed. Although it's possible to get people to collaboratively agree on priorities. I've had a lot of success with putting stakeholders together at at table, making them write down what they want on cards, and then saying, "Ok, put them in strict linear order of delivery." It helps to give them a bunch of cards with "RELEASE" written boldly on them.
I once did this with 25 people representing a dozen different nonprofits, and I've done it many times at both startups and large companies, so I know it can work. Every time, people try to put things side by side. But if I gently say, "strict linear order" enough times, everybody gets it. And then they start discussing, negotiating, planning.
Basically, they gave out poker chips that represented the available engineering capacity for the quarter. And then had everybody discuss and persuade until they arrived at a quarterly plan.
As you say, the trick is to have some way to make sure people don't overallocate, which they dearly love to do. With that in place, stakeholders stop fighting with engineering and instead wrestle with one another, letting engineers quietly get on with popping things off the backlog and shipping them.
> [...] 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.
The way I've always tried to solve that is to have a single person (often a team lead, unfortunately) become that singular frontman, who listens to the n parties but is the one combining their input into one decision. That is, take away n-1's access to edit the issues, tell them it's an internal tool, and they should talk to the one person. And if you disagree with the frontman, that's between you and them, not between you and the issue tracker.
This really is what a product manager should be doing (but I rarely see that actually work).
Of course, corporate politics means people try to find a way around them.
> There's always that moment when you don't feel like picking "the one at the top".
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
To tackle this, I highly recommend the percentile technique from MIT paper, "A Structured Approach to Strategic Decisions". [1]
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.
I had to read up on the "means of production" because I had no idea previously that it often refers to the capital (both social and financial) used to produce goods. It's interesting to me that Engels says (in essence) that a worker lacks the means of production and is therefore forced to sell their labour.
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.
This post solidifies an idea that’s been kicking around in my head: software tends to push productivity towards a local maximum.
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".
In general tickets describe change requests, and they are sometimes referred to as such (CRs): Someone wants the software/system to change in some way.
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.
This analytical approach is exactly what I disagree with.
> 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)
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.
This analytical approach is the reality of managing tickets taking technical and business realities into account.
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.
I'd agree with you if I would be only seeing the teams through my management reports and not from the trenches.
I am envious of the environment where you never saw somebody trying to bug feature request as a bug. I do think in a lot of cases, it's a judgement call...or a habit where problems perceived as bugs by customers are swung under the carpet as features as bug is only defined as "deviation from requirements".
Fair on distinction of severity by customer vs priority by team, although I am used to make a distinction between support ticket by customer and issue in engineering team's queue.
Lead implies either managerial or technological leadership and especially in mature organisations, I've seen both.
My experience with management by bug statistics is...very inconsistent as it motivates people to game the system...and boy I've seen that a lot. I do agree trend knowledge helps, but I am not sure it's worth the side-effects and work.
Of course, a flavor of this depends on context (and scale). It is very different if you have a single-instance SaaS, distributed system or images shipped to air-gapped systems.
> I am envious of the environment where you never saw somebody trying to bug feature request as a bug.
Really, I have never seen that in 20 years.
Of course that is different from another team or the test team raising a bug because they expected something that was not in the spec. Then you tell them that it's not because it does not behave the way they want that it is a bug.
But, yes, a defect (more general term than bug) is any deviation from requirements.
Direct input from customers is different as well. Unless there is a contractual impact, if a customer is adamant something is a bug when it technically isn't then there is no point arguing. You can treat the request however you want internally.
> It also means people will try to disguise feature requests as bugs in order to get a priority.
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).
The central point that work trackers track work is true important and jira astronauts need to be stopped, but the piece misses the bureaucratic purpose of jira: work legibility.
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.
There may be a similar legibility point about severity levels. Some boss somewhere has to put the set of tasks in priority order for the development team, and once it's in that order, severity levels are useless for the developers. But they might be useful as a way for the person submitting the issue to communicate something to the boss who does the ordering.
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.
I am proposing that the clerk should assign the severity.
You could have the programmers do the prioritisation, if they had the business understanding to do that. In that case, they're also the boss. The severity assigned by the clerk could still be a useful starting point.
> 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.
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).
> There is one good argument in its favor [closing tickets that are too old]: the software continuously changes and hence old issues may be invalid. In order to put them into a sprint, they need to be checked—in some cases, that’s actually more work than the issue itself.
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.
For a pretty crazy take on this, take. A look at BaseCamp’s “Shape Up” philosophy, They do not have a backlog. Period. To them, they work a little slower and expect to give enough time to a task to ensure zero bugs instead but then have cycles of bug-fix focus. Additionally, something I found interesting is that every dev is expected to understand the complete stack, that way any dev can fix any corner. Sure this might not work in a larger company without strong levels of splitting up the product, but It’s an enjoyable thing to look at.
A bug should identify where it was introduced. If a bug was introduced in version 0.5, then version 0.5 forever has that bug, and so the issues is forever valid in that sense, as a truthful comment about a historic thing. If the current version is 1.2, and it has not been confirmed to have fixed the bug, the view should be taken that the bug still exists in 1.2. Bugs don't just become invalid; if we are justified in calling a bug invalid now, that can only be because it was never valid in the first place.
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.
> One way to recover is to automatically close tickets after a certain period of time.
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.
Agreed. Github's Stale Bot is the most infuriating, aggravating and insulting bot in widespread use. Every time I encounter it, I reevaluate whether or not I even want to contribute to the project.
Interesting read - to a person working tickets, I think it can be true that there is no useful difference between viewing a task as a bug vs a feature - in either case, its "what needs to change" and performing work to do the change.
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.
> 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.
This is the most logical, sensible comment in the thread. Jira is the most flexible system for workflow management in existence. The fact that it is extensible is "a feature, not a bug."
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.
I completely agree and I hope I explicitly mentioned it in the article: it's not Jira, it's about how people/organizations often think about the problem.
I like the analogy. I'm trying to get people in my organization to understand that it's not a bug when a feature works as specified in the app requirements. Either the requirement wasn't specified well or a change of circumstances requires it to work differently. In either case, it's a request for modification not a bug. Your analogy should help me explain the difference.
The user doesn't care whether the bug is in the requirements or if it's in the code. They just know that it's not working for them, and want it changed.
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.
Whether it's a bug or a modification to requirements I'm still the one who works on it. So "not my problem" doesn't exist in my situation. The distinction matters very much when it comes to prioritizing my work. I'm 100% time on projects and jump from one to the next with no pause between. I'm also the only developer who supports the apps I built. Bugs usually jump to the top of the queue. Management puts a lower priority on requests. In order to not hurt my current "customer", I need to make sure past ones don't try gaming the system by declaring bugs when they're not.
It is very common for companies to forget how to properly prioritize between bugs and features. Trying to reinforce this by trying to teach them how to correctly (according to person on internet) classify bugs or features still sounds like a complete a waste of time.
there's a -- critical -- feedback loop problem that you're ignoring. sure, you might work on it with the same priority regardless of characterization. but if it's properly classified as an error in specification, that is extremely valuable information for process improvement.
Right, to the customer it doesn't matter (just like to the developer it doesn't need to matter either - it just means the work needs to be performed).
However, it matters greatly to other observers - if one person or team is highly out of the norm for rate of bugs, it might be indicative of other problems that need to be worked on (lack of testing, peer review, tasks being assigned beyond the working abilities etc.).
Just like the restaurant analogy - the expectation is that bugs shouldn't be happening to begin with, and when they do, it should be "our fault" to remedy them.
Yup - from a implementation perspective, bug vs feature is a artificial designation.
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.
One way the distinction gets used where I work is to have custom / required fields keyed on the ticket type.
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".
Earlier this year, I reported a bug in Firefox. In my report, I included steps to reproduce the issue, the expected result and the actual result (because I've been on the other side). There were no back-and-forth messages to clarify the issue, and it was fixed in a short amount of time (well, short for a project of that size).
Whoever is giving your team heat about bug metrics needs to read about Goodhart's Law.
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?
I do agree completely on "failed promise" and this is actually why I think the bug vs feature is flawed. I think "failed promise" is a great ticket type though ;)
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.
> They should be a unique set of priorities, with only one single ticket occupying #1 priority, another slightly less one in slot #2 etc.
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".
I don't know that I've ever seen a feature that wasn't some sort of "failed promise". The feature sometimes hits and sometimes misses, and is usually somewhere in between. This idea that a defect is a failure of a feature is probably more to do with the inability to predict the future. Sure there are defects like you tried to read from /dev/null, but more realistically the "defects" you see today are more about the inability to predict exactly how a feature is going to be used.
I love the restaurant analogy - it has great resonance especially if you consider cost of making it right.
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.
As a developer, I generally find having a distinction between bugs and features useful.
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 find it useful to differentiate bug from feature because they have a very different information set associated with them. Bugs need to provide description, steps to reproduce, expectation, observation, workaround and are require a write up as part of their completion (root cause). Features, on the other hand, need only a requirements list.
On point in so many ways... There is simply no way of decentralize prioritization. Thanks Almad, for sharing valuable insight/realization with the rest of us.
It sounds to me like you're describing Pivotal Tracker (https://www.pivotaltracker.com/). It forces story ordering (rather than "prioritization"), it's pretty barebones, and it's fast.
But if they're not called bugs, there is no blame game. And extra pressure can't be put on developers to . . . to shape up! Sense of urgency and all 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.
I disagree. Who is sorting those tickets? Are they sorted arbitrarily or were the technicals considered? Is the ticket at the top feasible given the current state of the codebase/product?
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, the final sorting needs to be done by a collaboration between ticket manager and someone-who-understands-technology anyway. If the ticket manager doesn't have a clue, they can't make judgement calls necessary as for nontrivial software, it can be hard to say if this is one day or one year of work.
They are sorted according to the project roadmap, usually by a person who understands business requirements, and a person who understands reality.
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.
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.
> 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.
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.
Github issues works pretty well for almost all software projects. A single list of issues viewable/searchable by the whole team, simple commenting, code referencing, tagging, assigning to people.
We tried Jira but became tangled in a mess of complex configuration and endless confusing UI's...
For most projects, sorting leads to prioritizing, which is an anti-pattern. For those who choose to eschew proper software development practices, it is nice that Projects is its own thing.
I don't think that prioritizing in general is an anti-pattern. You will do things before other things and you need to choose what to do first. The criticism in the article was about bad prioritization. With GH Projects you can have the liberty to queue issues however you may see fit.
The anti-pattern is premeditating priority. It is true that you have to consider all angles and ultimately determine where to start, but once you've done that it makes no difference where an issue lies in a list.
It’s more than that though. Once the list is sorted, the next time you come back to it, the list is still more or less in the right priority. So the work for prioritization becomes easier.
That doesn't seem the case in projects I worked with. In my case, there were more features than engineers and some features were more important than others, so the list made sense. Obviously, it's not set in stone. Features can sometimes jump queue, be completely dropped, or more important features can show up. But I don't think I was ever in a position when a broad list of tasks for the quarter didn't make sense.
Features are emergent out of solving the business needs. If you see a business opportunity in toasting bread, it wouldn't make sense to have an outstanding issue that says "Affix fireplace to the bottom of the apparatus". Instead, knowing your business goal, you start to think about how bread should be toasted and when you come to the revelation that an electric coil is the most efficient method to solve your problem, you finish adding it to the product and then revisit what your next business need is in the context of what now exists and what you have learned in the meantime.
Issues only come into play when your understanding is wrong, to serve as a reminder to revisit your assumptions. New features don't fit. If you are spending so much time finding features to develop faster than you can develop them, your human resource allocation is flawed.
It all depends on the business and business model. For instance, I worked in a classroom app. We had a few goals per quarter but let's just see a couple. For instance, one goal at a certain point was to create all these new lesson types. However, some were clearly more important than others (the ones which were used in almost every lesson was more important than one that's used in a couple. For bigger lesson types there may be more than one issue. For instance, being able to select a single option in a multiple choice lesson can be done before the feature to allow multiple selection and things like that.
Another goal that would frequently appear is paying tech debt. Some changes are also more important than other in that track.
All this work has business value and may be part of the BAU of a established business. I think you're describing a business in a very primordial state. Although, even in startups I've created having a list of things we wanted to do was helpful. We saw our competition we wanted to do better, but we also need to catch up. Lots of things are just obvious and not all the work one does is revolutionary. I don't disagree that changes do occur, though.
We use priority tagging, which allows you to group collections of bugs say: "urgent" . But yes it's hard to actually order the priorities... Haven't tried github projects yet
You only need something more complex or heavy than GH issues (if even that complex) if you've got someone bugging you for burndown charts and metrics and shit just all the time, or someone in the chain who just loves poking around and dragging shit from here to there ("oh goody I'm going to drag this into 'on ice', best day ever!"). The dragging action I don't bring up accidentally—it's very important, for some reason.
I feel the same way about Asana and Jira. They're so customizable and cater to too many people that it requires management to be someone's full time job. And I haven't found someone who is passionately in support of such as service as you might find with say Notion.
I've been working on a project that is attacking this problem but from the TODO comments angle. https://cosmolabs.io
Working in Jira and (especially) Asana always feels like working on a VNC share of the person in charge's cluttered desktop-covered-in-folders organizational system. Everything's hard to find and I'm afraid to touch anything for fear I'll accidentally drag something somewhere then not be able to find it again to put it back.
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.
Sometime I wish that my project was managed in a folder with neatly arranged subfolders all in ASCII text. Specs in the specs-folder. Release lists in the release list folder.
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 ...
> there should be an algorithm that everybody should agree on. An example may be:
> - 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)
"Downtime" as a consequence of an issue is 'severity', not 'priority'. But yes there needs to be a clear and consistent definition of what the different levels of severity mean. This is usually the case because people will quickly notice that it quickly gets messy if everyone makes up their own.
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.
I think you misunderstood his point. He is saying that in his system severity == priority. His article he linked lists out explicitly his buckets.
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.
I must confess I've never really understood the need for "severity" in a task tracking system.
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?
"Severity" is a measure of how serious the impact of a defect is (Using the term "impact" instead of "severity" can make things clearer). It does not say anything about the priority that should be assigned to fixing it, though it is obviously often correlated.
Severity is an absolute metric, priority is a relative metric.
In general the person who creates a defect ticket sets its severity based on what has been observed. The priority is set later by project management.
> 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.
Exactly. There may be a severe issue but because it happens so rarely it is probably not urgent to fix and thus may be assigned a low priority.
Of course if the issue "prod is down" is both severe and urgent to solve. But after investigation you may find the root cause and determine that it is costly to resolve while occurring only very rarely and thus that root cause issue may be low priority though it is still high severity.
The difference really is useful in practice where the effort and cost of solving issues may not be trivial (large systems and systems involving hardware for example). I have seem severe bugs that were tracked down to ASICs deployed in the field, so very expensive to fix, and for which the fix was deferred to the next product version because it was determined that the issue was rare enough that customers could live with it until then.
One missing thing: maximize the number of things that can safely avoid going through the bug tracker, because the tracker represents overhead and (even more importantly) latency.
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.
This describes Pivotal Tracker almost exactly. You can go into it cold turkey, but to get the best use out of it, it helps to be familiar with the Pivotal software development process.
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.
Something this article completely overlooks is coder mental health. Working on bugs constantly is the equivalent of being a code janitor. Getting to own/run a new feature from time to time can re-invigorate your interest.
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.
I'd say quite the opposite. What you say is one of the myriad of considerations that should go into prioritization by the team, yet is super hard to capture by any hard attribute as I believe the "positive/negative mental health effect" is way more complicated than "bug/feature", yet known by the team.
203 comments
[ 0.22 ms ] story [ 243 ms ] thread“then ‘upkeep’ and ‘new’ should be the ticket types”
Is "Make app work on device X" or "Add cornercase Y" new or upkeep?
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.
What's the diff if any?
But, since Taiga is FLOSS[1], anyone can host it and/or build a business around it, which -I suspect- is what taiga.pm does.
[1] https://github.com/taigaio
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.
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.
A standard ticket pipeline might look like this: Backlog > Review/Estimate > In Progress > Internal Review > Testing > Client Review > Feedback > Testing > Release
But the rapid pipeline will be more like: Create Ticket > In Progress > Testing > Release
This leaves the ball almost entirely in the developers court, and removes any step that requires waiting for feedback from the client or even the Project Manager.
So you can see the risk factors pretty quickly, with no review steps what if the developer gets it wrong? So that leaves the Project Manager some important questions: Is this ticket concise enough to be rapid? No room for back and forth discussions or muddy details. Is this ticket small enough to be rapid? Can't be a big new feature that's just being framed as urgent but could realistically wait. Can I trust the developer to get this right with no review? If you can't, then it's probably best it goes through the standard pipeline with the review steps anyway.
In big enough teams it can help manage workload, you can leave a specific developer intentionally under-utilized so that they have space for rapid tickets. During their under-utilized time they can be open for mentorship/learning/pair-programming until a rapid ticket pops up.
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.
I'm fine with ticketing systems for handling immediate work in progress. Which, incidentally, is what they're meant to be used for. Every time I've ever seen people try to juggle business priorities and long-term goals in a ticketing system, though, the end result has always struck me as being something of a failed experiment to develop a product that works well as both an ice cream topping and an engine lubricant.
I bet there'd be circular comparisons (A>B>C>A) a surprising amount of the time. Not a huge deal, you could just show the pairings back again in a different order until they resolve.
It connected with the Reminders app and the Wunderlist API. I wonder if I could revive it with more services…
It works fine, except that the product is complex and old enough (and the team has too few developers so) that the bug queue rarely gets to zero.
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.
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.
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.
The argument from privilege frankly confuses me. I've applied the same principles both when I've been the underdog and the one asking others and it's good guidance since it also gives you input whether you want to work where you currently are. Sometimes I've had harder times because of it, but I've never stayed in an abusive work relationship.
So during the meeting, I said: that bug is just a sympthom, the module needs to be rewritten. And I knew what I was talking about.
No, said a senior, we're just going to fix the bug, no rewriting. I said that's your call, but I sure am not going to fix that bug. I can tell you: nobody listened to me.
So he more or less finished the discussion and said: I'm going to sit down with you, and we're going to fix that bug. And we did.
At that point it was the right call.
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.
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:
https://twitter.com/swardley/status/1082647878349324288
"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
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.
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.
I once did this with 25 people representing a dozen different nonprofits, and I've done it many times at both startups and large companies, so I know it can work. Every time, people try to put things side by side. But if I gently say, "strict linear order" enough times, everybody gets it. And then they start discussing, negotiating, planning.
Another approach, one that works if your teams are established enough that you can give good engineering estimates, was what Rob Fan at Sharethrough used for quarterly planning: https://www.slideshare.net/rfan622/launch-scale-presentation
Basically, they gave out poker chips that represented the available engineering capacity for the quarter. And then had everybody discuss and persuade until they arrived at a quarterly plan.
As you say, the trick is to have some way to make sure people don't overallocate, which they dearly love to do. With that in place, stakeholders stop fighting with engineering and instead wrestle with one another, letting engineers quietly get on with popping things off the backlog and shipping them.
The way I've always tried to solve that is to have a single person (often a team lead, unfortunately) become that singular frontman, who listens to the n parties but is the one combining their input into one decision. That is, take away n-1's access to edit the issues, tell them it's an internal tool, and they should talk to the one person. And if you disagree with the frontman, that's between you and them, not between you and the issue tracker.
This really is what a product manager should be doing (but I rarely see that actually work).
Of course, corporate politics means people try to find a way around them.
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
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...
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.
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".
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)
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.
Yeah, this is something worth a separate article (this one felt long already): ticket systems as reporting tools.
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.
I am envious of the environment where you never saw somebody trying to bug feature request as a bug. I do think in a lot of cases, it's a judgement call...or a habit where problems perceived as bugs by customers are swung under the carpet as features as bug is only defined as "deviation from requirements".
Fair on distinction of severity by customer vs priority by team, although I am used to make a distinction between support ticket by customer and issue in engineering team's queue.
Lead implies either managerial or technological leadership and especially in mature organisations, I've seen both.
My experience with management by bug statistics is...very inconsistent as it motivates people to game the system...and boy I've seen that a lot. I do agree trend knowledge helps, but I am not sure it's worth the side-effects and work.
Of course, a flavor of this depends on context (and scale). It is very different if you have a single-instance SaaS, distributed system or images shipped to air-gapped systems.
Really, I have never seen that in 20 years.
Of course that is different from another team or the test team raising a bug because they expected something that was not in the spec. Then you tell them that it's not because it does not behave the way they want that it is a bug. But, yes, a defect (more general term than bug) is any deviation from requirements.
Direct input from customers is different as well. Unless there is a contractual impact, if a customer is adamant something is a bug when it technically isn't then there is no point arguing. You can treat the request however you want internally.
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).
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.
Yet I refuse to do it to them, the ICs.
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.
You could have the programmers do the prioritisation, if they had the business understanding to do that. In that case, they're also the boss. The severity assigned by the clerk could still be a useful starting point.
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).
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.
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.
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.
Oh no.... You are wasting yours and theirs time. This is such a developer thing to do.
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.
For a few companies, sure. The chance that he's working on one of those is zero (based on what he has written so far).
However, it matters greatly to other observers - if one person or team is highly out of the norm for rate of bugs, it might be indicative of other problems that need to be worked on (lack of testing, peer review, tasks being assigned beyond the working abilities etc.).
Just like the restaurant analogy - the expectation is that bugs shouldn't be happening to begin with, and when they do, it should be "our fault" to remedy them.
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.
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.
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".
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?
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.
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".
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
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.
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.
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.
And that affects prioritization a lot.
This involves adding a triage column before the todo column. This column is for tickets that are necessary, but not prioritised or ready to work on.
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.
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.
We tried Jira but became tangled in a mess of complex configuration and endless confusing UI's...
Issues only come into play when your understanding is wrong, to serve as a reminder to revisit your assumptions. New features don't fit. If you are spending so much time finding features to develop faster than you can develop them, your human resource allocation is flawed.
Another goal that would frequently appear is paying tech debt. Some changes are also more important than other in that track.
All this work has business value and may be part of the BAU of a established business. I think you're describing a business in a very primordial state. Although, even in startups I've created having a list of things we wanted to do was helpful. We saw our competition we wanted to do better, but we also need to catch up. Lots of things are just obvious and not all the work one does is revolutionary. I don't disagree that changes do occur, though.
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 ...
A FIXME cannot be in master, but TODO's all the time.
> - 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.
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.
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?
"Severity" is a measure of how serious the impact of a defect is (Using the term "impact" instead of "severity" can make things clearer). It does not say anything about the priority that should be assigned to fixing it, though it is obviously often correlated.
Severity is an absolute metric, priority is a relative metric.
In general the person who creates a defect ticket sets its severity based on what has been observed. The priority is set later by project management.
> 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.
Exactly. There may be a severe issue but because it happens so rarely it is probably not urgent to fix and thus may be assigned a low priority.
Of course if the issue "prod is down" is both severe and urgent to solve. But after investigation you may find the root cause and determine that it is costly to resolve while occurring only very rarely and thus that root cause issue may be low priority though it is still high severity.
The difference really is useful in practice where the effort and cost of solving issues may not be trivial (large systems and systems involving hardware for example). I have seem severe bugs that were tracked down to ASICs deployed in the field, so very expensive to fix, and for which the fix was deferred to the next product version because it was determined that the issue was rare enough that customers could live with it until then.
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.
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.
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.