33

We work in scrum teams with a product owner who is responsible for the backlog and prioritisation of that backlog. Recently the topic of un-ticketed work came up, developers for one of the applications are doing un-ticketed work that they regard as important. Typically this is tech debt but can also be things like migrating to a better library etc.

The argument from the developers was that these are generally small things and in an agile team they should be able to exercise their judgement and fit them in around sprint work. E.g. if waiting for the CI system to build and deploy they could tidy up some code. The effort of raising a ticket will take longer than actually doing the work. The work being done is tested via automated tests and so there is no additional burden on the QA members of the team.

The argument against this is that the developers are effectively saying their opinion on what work is a priority is more important than any other stakeholder and are not going to go through the PO so it can be compared against other work in the backlog. There is also a case to be made that if a developer has spare time then it would be more productive for them to be elaborating upcoming stories. The state of stories coming into sprint has been raised at retros before and so more elaboration can only help this. There is also a concern that the self policing of what size falls into this category may start to stretch and result in even more time being spent on un-ticketed work.

I can see both sides of the argument to an extent but should all work no matter how small be ticketed and go through sprint planning rather than be done as and when by developers if it is small?

  • 32
    I'm a developer, so I might be biased. But I'm with developers here. I currently work on a product where we have strict machine-enforced policy that no code change can happen without a Jira ticket. And it is easy to see what that kind of policy has on a codebase, as project accumulated huge amounts of technical debt and fixing it would mean going through emounts of bureucracy that no one seems to be willing to put up with. – Euphoric Apr 1 at 16:46
  • 3
    I think this quesion will vary wildly depending on what is goal of having tickets for work. Are they for coordination between people? Work and capacity planning? Keeping of work history? Analyzing flow of work? – Euphoric Apr 1 at 16:52
  • 37
    If the work done to conform to a process is more than the actual work accomplished then you have a broken process. – 17 of 26 Apr 1 at 19:41
  • 4
    @FrankHopkins It is difficult and time-consuming to build a valid business case for refactoring. It is not uncommon to spend 1 day of work time and 2 weeks of wait time build a business case for a refactoring that takes 1 hour. That is clear waste to me. And demonstrates lack of trust of business in engineers. – Euphoric Apr 2 at 5:28
  • 18
    I think your question suffers becausd you are essentially asking a community of developers to vote on whether they want to do more admin work or whether they should be trusted to do what they think is best. – Ewan Apr 2 at 7:06
53
  1. If you work in a company that doesn't place any value in paying down technical debt, you may have no choice but to do unticketed work.

  2. Stakeholders are generally not qualified to make decisions about this kind of work.

  3. Include unticketed work as part of your ticket estimation process.

| improve this answer | |
  • 2
    well, if you estimate it into your tickets, it's not unticketed ;) Imho, proper refactoring of stuff you touch belong into the ticket estimations anyway... – Frank Hopkins Apr 2 at 1:57
  • 2
    If your Scrum-Team really works as a team together with the PO, you as a software developer are a stake-holder as well, since you have to work with the code and usually have to fix bugs. So often it is just a communications issue for tech-debt to get prioritized. - Working around the system without even trying to work with the system is toxic... – Falco Apr 2 at 13:11
  • 1
    @l0b0, you overlook the possibility that they may not be "allowed" to do unticketed work in any formal sense, but are doing it anyway because management don't have any power of oversight, which would be perfectly in-keeping with such management's lack of understanding overall. – Steve Apr 2 at 14:00
  • @l0b0: Naturally, finding a new job is always an option. I'm saying that doing reasonable due diligence ought to just be part of your job, whether management thinks it is nor not. You don't put someone onto the freeway in a rickshaw. – Robert Harvey Apr 2 at 19:02
  • @l0b0: It's not what I "like;" it's what the moral imperative dictates. I can release crap that makes my fellow programmers' lives a living hell while still barely meeting functional requirements, or I can leave the area a little cleaner than when I arrived and lay the groundwork for making future changes easier. Is that a personal choice? Perhaps, but as I stated in my answer, the stakeholders are not qualified to make it. – Robert Harvey Apr 2 at 19:12
29

In a few safety-critical industries, you need approval for every bit of code that goes into a product. Most people are not in that situation, and those that are, accept that condition.

In normal situations, if you don't allow for unticketed work, you are basically wasting the experience of your engineers, especially senior engineers. They know about things that will improve the customer experience but that a customer would never know to ask for. They know ways to accomplish your stated goals that are better than a proposed solution. They know about things that will improve the developer experience, making developers more productive and happy, and indirectly getting customer requests out the door more quickly. Conversely, they know about things that could make customers angry, and can prevent problems before they happen if given enough latitude.

How do you keep developers accountable for that work? By telling the product owner about all of it, even if you don't always ask first. That way, the product owner can make priority calls if you end up spending too much time. Our PO attends every standup, so he never goes more than a day, and usually no more than a half day, without knowing what unticketed items we work on. If we think something will take more than a couple hours, we run it by our product owner first.

Part of the reason this is efficient is because the more people involved in a decision, the longer it takes. A developer can have something done in an hour, or he can get a ticket created that might take a dozen man hours to explain, analyze, and prioritize. As long as there is oversight so it doesn't push business priorities aside, you're actually saving money.

| improve this answer | |
  • 1
    I think one can contrast work done without thinking a lot about it (like cleaning up some comments while the code compiles) and conscious decisions to start a chunk of work (like updating to a new major version of a dependency) - and for the second ones, if a dev is thinking about and deciding to start this task, he should have the time to inform his team/po about it so they can take part in the descision and possible side-effects. – Falco Apr 2 at 13:39
  • Yes, of course. The wider the impact or the more controversial the decision, the more people need to be involved. – Karl Bielefeldt Apr 2 at 13:52
  • 1
    If you stop your developers from doing this, you also waste their paid time. Because what will happen is not, as you might expect, that they create tickets and whatnot. What will happen is, that instead of fixing small things during CI build time, they will read news on the Internet, watch YouTube, chat (and stop others from working because of this) etc. – Josef says Reinstate Monica Apr 3 at 16:16
12

should all work no matter how small be ticketed and go through sprint planning rather than be done as and when by developers if it is small?

There's certainly a point where the answer is no, right? It doesn't make sense to add a ticket to open the IDE, or to format the code before checking it in, or to code review other's code. One could argue that those tiny things are all part of an existing ticket - but so is cleaning up tech debt around the stuff you're working on.

The biggest thing people forget is that process is there to serve you, not vice versa.

If making the ticket is more valuable (in visibility, consistency, etc.) than the cost (in time to make it, context switching, noise to the backlog, opportunity cost of not doing something else), then do it. If prioritizing these things is more valuable than the cost, then do it.

| improve this answer | |
  • 2
    "The biggest thing people forget is that process is there to serve you, not vice versa." Except when the process is there to serve your boss or the business, instead. – nick012000 Apr 2 at 1:28
  • @nick012000 maybe shortsighted - but in the overall picture it is you who delivers actual value to the project, the actual team members working are the only ones producing anything - and all the process can try to do is to help them produce better. – Falco Apr 2 at 13:21
  • In many teams I worked, we simply had a place-holder ticket "working on technical debt" which we included in sprint planning with an amount of points how much time/energy we wanted to invest into it and to make it visible to the PO, without specifying in details what 50 little tasks would actually be done under this umbrella. - be pragmatic – Falco Apr 2 at 13:23
  • 2
    @nick012000, except when the process is there but actually serves nobody. The concept of dysfunction does exist, and software processes exhibit a lot of what I believe is called "mimetic isomorphism", in that organisations emulate each other (or more often, partly emulate each other) without having the slightest idea of what is being achieved by it or how. – Steve Apr 2 at 13:49
  • 2
    "Cargo Cult" is the more well known term. – Telastyn Apr 2 at 17:44
6

Lets differentiate a bit, you can have many types of unticketed work

  1. Doing something completely unrelated to project, eg. helping someone on another team, admin, management meeting

  2. Implied by specified work. eg. no-one mentioned security, but we are just adding the default rather than pestering for specs

  3. Gold plating. eg. of course you want animations on those buttons!

  4. CV driven development. eg. I refactored to ${latest thing}! it will be #better

  5. Shadow IT. eg I did the DB backups for X even though its not my job, because I'm de-facto the DB admin.

Obviously some you would want people to do without a ticket, some you wouldn't.

Ideally you want all of your developers time to be accounted for and project focused but you have to put the work in to make this happen. Assign time for those PDP meetings, Hire a DBA, provide full specs for the hard stuff, specify exactly what you want and don't want

Trying to do this properly is a massive unloading of work from the devs to project managers. But if you can do it your velocity will skyrocket.

| improve this answer | |
  • 9
    "Ideally you want all of your developers time to be accounted for and project focused" No you don't. Sprints and ticketing are project management techniques, not people management. They do not, and are not supposed to capture the entirety of what a developer is doing. What the tickets and stories are supposed to capture is what work is being done currently and in the near future, and that can be extrapolated to see if a project is on track. It does not and isn't supposed to be used as a time tracking tool, and using it to track developer work is an antipattern – Gabe Sechan Apr 2 at 3:13
  • 3
    No, you don't. That's not the purpose of a ticketing system, or for project planning. The purpose of those is to keep track of project progress and what still needs to be done- not to manage people. If you're using it for that, you're doing things VERY wrong. – Gabe Sechan Apr 2 at 6:21
  • 2
    the purpose is to make sure you hit your deadlines. I assume your projects are all delivered late by number of holiday days the devs took because this is 'people management' and you dont include it in your planning – Ewan Apr 2 at 7:02
  • 1
    The way it actually works is you break the work to be done into tickets, and you estimate each ticket. Then you track how fast you do compare to those estimates. Based on data, you re-estimate regularly. If you're off track, then you decide whether to increase resources, push back, cut features, etc. But you don't use tickets to try to micromanage the engineers- not only does that not work and create overhead that costs more time, but it harms your actual ability to track the progress of your project. – Gabe Sechan Apr 2 at 9:06
  • 3
    @Ewan So what do you do if something is not on schedule? What if someone gets sick? What if something just takes longer than you thought? Do you literally have tickets for "doing dumb mandatory training" and time tracking for "doing code review"? Sounds awful. – user3067860 Apr 2 at 12:54
4

Play Ball

The ticketing system is there. It is the rules. Now get creative.

1) Leave.

If you don't want to play ball.

Maybe on principle, or maybe its simply too arduous.

Don't stay and complain when you can be elsewhere living it up.

2) Play by the rules.

Spend your time doing exactly what the higher ups are asking for.

Just don't be nasty about it. Upfront and professional, if they try to push past you simply point out the rules and say that under them it cannot happen. Point out what would be preferable and the advantages of the approach, and ask politely for it to be changed.

So, If they want you grooming stories. Go and groom. The estimates will eventually grow and grow. And they will complain. You simply point out that no unticketed work is being performed, and that none of the problems are being ticketed as they have directed you to upcoming project work only. If they want the estimates to go down. They will need to ticket for code debt, and schedule it in.

Which brings us to, if they demand that the work is ticketed and submitted for prioritisation. Go and ticket. Spend that time identifying each and every problem. The number of tickets will grow and grow and they will complain. Point out that all code debt related work is being identified and that these are pre-requists of many substantial pieces of work. They will push through project work. Ticket each hack and kludge needed to get that work in.

Eventually they will try to deal with the deluge of tickets by just closing them. Point out that this is against the rules unless you as a stakeholder you also have the ability to close their tickets.

Again don't be mean about it. These are the rules, you are acting accordingly. You would prefer this alternate system, with particular advantages.

Sell them on a compromise. Your team gets to action small changes, in exchange you fill in a ticket with commit, doer, time taken, intention and a brief description.

  • commit to track the "small" change
  • doer to identify well you, you deserve acknowledgement for your work
  • time taken, because people like to count rice grains.
  • intention, because a semantic grouping is always good like: dependency update, code cleanup, code refactor, dead code, code coverage.
  • a description because the business folk can't read code and don't have access to the scm.

If they agree to change congratulations: you have helped your business maintain an agile edge to it.

3. Break the rules.

Just do it anyway.

Be subversive against the company culture. This is a rebellion! Throw off the chains of the old system.

Just don't come complaining when you eventually run into the thing that the system is supposed to deal with.

You broke it, you fix it, and pay the price for it.

Those who come after you may have a bloody mess to deal with, or an idyllic paradise. What do you think the chances are?

Also please hang up any semblance of professionalism on the way out the door.

| improve this answer | |
  • I really like this. One big thing to take away from my perspective is in point 3. If you break it, others have to clean up after you, and if your customers write custom code to integrate to yours, you've just pissed off a whole bunch of developers who may want to start looking at an alternate, depending on how often you pull this stunt on them. Even a simple library upgrade can break code, especially if your customer has to use the same library, and they don't appreciate having surprises thrown at them, and now they have to figure out what undocumented change broke their work. – Tom A Apr 2 at 17:57
2

My rules are: 1. Nothing happens without a ticket and a code review. Ever. 2. Developers know what they are doing. If they think work is necessary then it is necessary.

So what happens is: You make the change, create a ticket with the lowest possible number of story points, assign it to yourself, add it to the current sprint, create a branch (all these in any order), then create a pull request. Then someone else reviews and merges. With a bit of practice you can do the bits other than making the change and the code review in less than five minutes.

If you are a developer who doesn't know what they are doing and make useless work, your changes don't pass the review, and if this happens often enough, you stop doing it.

| improve this answer | |
1

The argument against this is that the developers are effectively saying their opinion on what work is a priority is more important than any other stakeholder and are not going to go through the PO so it can be compared against other work in the backlog.

I wonder, is this a genuine argument?

The tone suggests the developers are suffering from a certain amount of arrogance in forming independent opinions at all, but it would be wholly unsurprising that developers form opinions on what work needs to be done (either as part of their general responsibilities for maintaining the integrity of the system, or necessarily entailed as part of a task they have been set about), and that their opinions may in many circumstances be the most important.

It would be more appropriate to try and agree sensible guidelines about what scale of unforeseen or unplanned work requires formalities. Half an hour here and an hour there is no time at all in software.

| improve this answer | |
0

From Agile Estimating and Planning by Mike Cohn:

You may want to consider including 0 as a valid number within your estimation range. While it's unlikely that a team will encounter many user stories or features that truly take no work, including 0 is often useful. There are two reasons for this. First, if we want to keep all features within a 10x range, assigning non-zero values to tiny features will limit the size of largest features. Second, if the work truly is closer to 0 than 1, the team may not want the completion of the feature to contribute to its velocity calculations. If the team earns one point in this iteration for something truly trivial, in the next iteration their velocity will either drop by one or they’ll have to earn that point by doing work that may not be as trivial.

If the team does elect to include 0 in its estimation scale, everyone involved in the project (especially the product owner) needs to understand that 13 × 0 ≠ 0. I’ve never had the slightest problem explaining this to product owners, who correctly realize that a 0-point story is the equivalent of a free lunch. However, they also realize there’s a limit to the number of free lunches they can get in a single iteration. An alternative to using 0 is to group very small stories together and estimate them as a single unit.

So, yes, if you're estimating all your tasks, include the "freebies" knowing that they're not truly free. I've very rarely had a task where writing the ticket took longer than the task itself, and ticket writing is hardly an arduous or long process. Write those tickets so the product owner can see the extra value that the developers are providing! Without them, they're doing invisible work.

The important thing to remember about Agile is that it's agile! If you try to use it too rigidly, it's not agile anymore!

Another thing to remember is that if you do estimate "free" tasks but fail to do them by the end of the sprint, they don't impact your velocity, as long as the number of unfinished "free" tasks is low!

| improve this answer | |
  • "Without them, they're doing invisible work." - they'll almost certainly be doing "invisible" work anyway, that is work that is not fully described or reproducible by any recording system. The only question is how much work is expended on maintaining the fiction that they aren't. Outside a space programme, show me a shop where every minute is recorded, and I'll show you software that does little, because they spend all their time dancing with the paperwork to make it look like they're working - and that dancing is how you know they aren't working on software. – Steve Apr 2 at 11:27
  • @Steve Yes but just because people always do some of their work invisible is no reason not to try to track a reasonable amount of it. If it were black and white, one should just give up on tracking any kind of work or progress, because they cannot track 100% - what I would strive for is tracking things as long as tracking them costs you less than not tracking them. – Falco Apr 2 at 13:29
  • @Falco, what is a "reasonable" amount is the crucial question, and anyone who thinks it is reasonable to create a cost estimate for every form of tracking, is not being reasonable. – Steve Apr 2 at 14:40
  • I've always thought that assigning 1 point to text changes and other near trivial tasks helped offset the optimistic bias most of us have in estimating the difficult tasks. Additionally, there may be work related to running the test suite, managing version control, all that other stuff. I've seen projects get derailed by a deluge of these little requests, and think it's good to keep in mind all changes have some cost and some risk. – Josh Rumbut Apr 3 at 0:48
0

should all work no matter how small be ticketed and go through sprint planning rather than be done as and when by developers if it is small?

Almost yes.

It generally depends on how critical the work is, how large the company/business/team is, how much accountable each participant/stakeholder/employee should be held, etc. But, if you don't ticket, you miss time. Yes, you read that right, you miss time (not lose) when you don't take it into account.

Say you are called to organize the team and produce estimates for something. However experienced, you will generally always want to rely on past data. And if you have data gaps, you need to interpolate. And you degrade the accuracy of your estimation. Short story, when you are planning ahead, depending on how efficient or demanding your scheduling/estimation techniques are (see, e.g. this), you may not be in position to afford to "exclude" observations, you need to know exactly how much time was spent, oftentimes on what precisely, so that you can make the most educated estimates possible.

developers for one of the applications are doing un-ticketed work that they regard as important.

The principle of least effort says that's a good thing... in fact, that's a great thing. It shows that your developers are devoted to keeping a fair level of standards and code quality.

The effort of raising a ticket will take longer than actually doing the work

Yes. Booting a computer ten years ago also took longer than taking out a pocket calculator to sum up 20 values. The wrong solution: keep using the pocket calculator. The right solution: make computers boot faster. What I'm trying to say is that you wouldn't want to skip evidence that would make you more productive just because your current process is not too efficient. Make the process more efficient. How? I don't know, find a way. Create another ticket type: "Tech-debt repayment ticket". Automate the heck out of it, make the effort equal to just the click of a button, make one button for every reason out there, if you will. Or introduce "tech-debt repayment time" that anyone can stock up on and use, and assign it as needed.

Think about employee attendance monitoring systems (card swipe machines, etc.). Your dilemma amounts to considering whether you can get by with some people occasionally not signalling that they are there to do work, because the process of marking their work is quite a chore. When it's pay-time, everybody will know, in retrospect, the value of missing data.

In general, the availability of data/information is of paramount importance, sometimes for reasons that may not even come to mind at the moment of collection. It has the potential to protect the employer, protect the employees, improve productivity, etc. In general, you cannot lose productivity just by having additional data, i.e. extra information rarely harms.

Of course, this entire organizational mentality may not be too critical for a relatively small development team and you may not generally want to put such type of "pressure" on the developers. However, you can always explain to them why it is important to monitor all work done (spoiler: so that you can make increasingly better estimates and manage available time when it is scarce). In any case, your mileage may vary, of course, hence the main answer to your question was almost yes.

| improve this answer | |
  • 1
    On estimating, having perfect past data does not produce an accurate future estimate, because there is still the question of whether (and to what degree) past activities overlap with what you propose to do, and more data is likely to increase the burden of collation. And the experience of having done something before may well change the timeframe (and crucially, estimates based on data from experienced workers will start to omit the true cost of reproduction of that experience). Also, "missing time" is not truly missing - you can always look at attendance records. – Steve Apr 2 at 11:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.