<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">
Skip to content

Reading through the /r/agile subreddit the other day, I recently came across the following question:

We are trying to implement LeSS in our company. Devs often work on various support tickets for customers. They are quite small like 2H or something like that. Should they be on the board? Should we estimate? Often they are quite a lot of them and devs even spend the whole day on support stuff.

Should we estimate? Should we just put them on the board without estimation? Should we just ignore them and not put them on the board?
Thank you!


As a services company specializing in Atlassian products, this question is one we commonly come across when doing Jira and Agile coaching. Clients look through their reports, and are initially perplexed by degraded team velocity. Though they are certain the estimates for feature and product releases are good, they never seem to hit their goals.

But why?

The culprit is often found in developer time being divided between working on feature enhancements and dealing with support. When this support aspect is not considered in planning, projects bleed time. From the question posed on reddit, the first paragraph has two indicators of this bleed. The first is that the tickets are small, only taking about 2 hours. Consider this: 2 hours is 5% of a 40 hour week. This is not a trivial amount of time to lose. Working four tickets a week will remove a full day from your developer capacity. This is affirmed in the second statement where the question author says developers will spend their entire day on support tickets.

While it might be grudgingly acceptable for a developer to lose a day or two occasionally, once this becomes standard behavior it becomes a huge threat to delivery. Before doing anything else, metrics should be gathered on how much time is really being lost to support tickets. When we do this analysis with clients, they are often shocked at the actual scope.

A second thing to do is consider if a team of developers dedicated specifically to support is warranted. If a significant portion of time is being spent on support tickets, it may be time to go down this route. This will add time back into primary development tracks in two ways. The first obvious way is that developers will no longer have their time slowly chewed away by support tickets. The second return on time is not as obvious, but is real. By working multiple small items not related to feature enhancements, time is slowly leeched away through frequent context switching. Over time, this will affect your estimates for feature items.

So to return to the initial questions from the reddit post, these issues should not be ignored. They need to be accounted for on the board. As far as estimation goes, since it is known that they are normally two hour tasks, use whatever estimation equates to the effort for a two hour task. This removes the need to do in-depth estimation for these support tickets. This doesn’t mean you can’t estimate any of the support tickets. If some jump out as possibly requiring more time, they should definitely be estimated.

Managing JIRA at Scale White Paper

See More From These Topics