Un-ticketed work, how much is too much?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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!

Answer 9

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.