Is tracking billable time for Scrum ceremonies in JIRA an anti-pattern?

Question

We use Story Points for estimating complexity of User Stories, but we bill hours to the client. This is the very first Scrum project within our company, and we don't have enough data to calculate a price per sprint.

I was asked by the executives to track all Scrum ceremonies in JIRA. In my whole Scrum career I have never encountered such a thing. My "danger alarm" is ringing loudly. I can see their point. As the project is running in Scrum, we should bill also "Scrum time" to the client the same way we bill Project Manager time in Waterfall projects.

I know, that "normally" we should bill Sprints with the ceremonies included, but we are not there yet. I try to be open-minded, I haven't found anything in the Scrum Guide against tracking Scrum time (e.g. framework overhead).

I can create a JIRA task in each Sprint, where we will clock time used for Scrum events. Is this technique strictly against Scrum?

Answer 1

The direct answer to your question is that how you bill your time to the client is not addressed in Scrum. Therefor there is no billing model that is expressly anti-scrum. If adding a place on the board where you track time is the easiest way for your team to keep tabs on it, feel free.

Now, there are billing models that can incentivize anti-Scrum behaviors. For example, if you are billing by the quarter-hour for every person in the Scrum event, the client may pressure you to leave people out of the meeting that should be included. That would be going directly against Scrum, but the billing itself is fine.

Answer 2

Scrum works best if you have good product ownership, fixed-length iterations and a stable team. If the backlog is determined by the client and the team is stable then (barring leave and unexpected absences) I would expect the cost per iteration to be fixed. So if you need to apportion cost per item then the right way is surely to divide the iteration cost (including events) by the relative effort spent on each story.

For a two week sprint I would anticipate Scrum events to be no more than about 10% of effort for the team. But the largest chunk of that is time spent with the PO (Planning, Review and Refinement), so if the PO is the client then the cost of events should be very visible and within their control anyway.

Lots of scrum teams do record hours done on each sprint backlog item, although often mainly for their own benefit, e.g. for optimising work and understanding the impact of blocking. If it's important to the client then I suggest you could record events on the sprint backlog (i.e. tasks) while continuing to estimate the product backlog using points. I don't see any great problem with doing that.

Answer 3

TL;DR

Scrum is based on an empirical control methodology. While not directly stated in the Scrum Guide, it essentially posits a roughly-constant run rate for each Sprint, allowing predictable budgeting through estimating the number of Sprints that are likely needed to reach a "good enough" target. (See Agile Release Planning for more on this.)

Generally, budgeting/billing should be based on the average cost of your Sprints (e.g. 7 people at 40 hours per week) rather than trying to get more granular. Scrum events are framework overhead, and billing them as separate line items isn't going to help anyone measure outcomes.

While your use case may be different, trying to bill framework process separately from hands-on development activities is a project smell. It strongly implies that management sees no value in planning, communication, or coordination, and will likely try to squeeze "overhead" to gain Pyrrhic cost efficiencies at the cost of essential inspect-and-adapt events. If they do that, they will likely break the process, and will get to keep both halves.

A Deeper Dive

I was asked by Executives to also track all Scrum ceremonies in JIRA.

You don't define your role in your original post, but I'm going to assume "Scrum Master." Regardless, this is a teachable moment for you, the Scrum Team, and the rest of the organization. Maybe even the customer, too!

It's a good bet that this is an X/Y problem. A good way to uncover the real underlying issue is to use the Five Why's technique. Consider this example chain of questions:

1. Why do you want time spent on Scrum events tracked in JIRA?
2. Why is it useful to track time spent on essential framework activities separately from other activities?
3. Why would management or the customer need to distinguish between different types of activities required by our internal processes?
4. Why would this information improve the development or delivery process?
5. Why would this information feed outcome-based KPIs and metrics?

This chain (or one quite like it that better fits your use case, and dynamically adjusts to the answers provided) will probably result in one or more root-cause statements indicating:

• Lack of trust in the team or the agile development process.
• Magical thinking, such as the 100% utilization fallacy.
• Organizational failure to buy into the values, principles, and objectives of an incremental or iterative process.
• A desire to use Buzzword Management™ to claim agility without actually committing to the framework.
• A management style that seeks a "go faster" button without a willingness to pay the costs in process and culture change.

Scrum is not a magical go-faster button. It's a framework that uses empirical planning to create a sustainable process with a predictable cadence. It can increase efficiency, but in this case efficiency means "doing more of the right things and building more of what matters" rather than simply accelerating the pace by getting rid of all that pesky project overhead.

Uncover the real intent of this management objective. If it makes sense, involve the team in determining how best to track it. If it's an exercise in futility, educate the management team (and possibly the client) on how Scrum really works and what levers the empirical control process provides them to manage costs, schedule, quality, and change.

Answer 4

I'm confused. You say you bill hours to the client. By that I understand "hours of work".

Scrum ceremonies are part of the work the team is doing. When you hold a daily standup for example, you do so in order for the team to coordinate their work in the sprint. You talk about work there, not the weather, or how your cat stuck its head into a jar and it was so funny... Why track this time separately? For what purpose? This is the most important thing to find out: "why"?

In more traditional projects, you track time on various tasks, to compare the estimated time with the actual consumed and use that to track project progress. Are we on track? Are we behind? etc. You also track project management overhead separately, like meetings, building reports, administrative tasks, etc. This is useful to see how much effort it takes to manage the project (i.e. the things needed to organize the work). Was this an easy project? Was it difficult to manage? Was it a normal project? Can we expect the same percentage of management overhead on similar projects in the future?

If that's the reason to measure time spent in Scrum ceremonies (i.e. to see how much it takes to organize the work, which in itself is work), then it might make some sense, even if it's only because of having this habit from your old methodology and finding it hard to shake.

But remember that the measure of progress in Scrum is working software, with work of most value first. It's not how many hours you worked compared to how much you still have left or estimated. Also, in Scrum, the ceremonies are time boxed. There is a top ceiling to how much time you will consume in what you call "Scrum time". It makes sense to measure this and see if you go beyond the ceiling, in which case that might be a sign of something happening, something that needs fixing or in need of being improved, but I still don't see how this "Scrum time" fits with the hours you bill.

How you bill your work isn't really a technique for or against Scrum. But the reason for "why" you might do it one way or the other might be. If for example you track "Scrum time" separately and someone doesn't like the number you get back, they might be tempted to reduce it. Why so many daily meetings? Just have one a week, on Monday. Retrospectives take too long? Don't do them anymore. etc. If this is your first Scrum project and you don't really know what you are doing, you'll end up with more problems than how to bill the client.

So find out why!

Answer 5

It is bad practice because Scrum has no ceremonies. Scrum has events and they serve for inspection and adaptation. Planning work and monitoring progress is not overhead but an integral part of the delivery process. This is clear in the Scrum Guide.

From the client's point of view, time-tracking is interesting because they do not want to pay for team lunch, QA weekly meeting, fire drill, security training, whatever, but it makes little sense to measure the time of Scrum events separately. And it is surely not in unison with the agile manifesto since the contract negotiation seems to be more important than customer collaboration. But turning your customer agile is way more difficult than turning so yourself.

On the other hand, no time-tracking system is perfect, so as long as billing and budgeting goals are adequately supported, it is somebody else's problem. The Scrum Master's authority plainly does not cover finance and legal stuff.

Answer 6

Lots of scrum teams do record hours done on each sprint backlog item, although often mainly for their own benefit, e.g. for optimising work and understanding the impact of blocking. If it's important to the client then I suggest you could record events on the sprint backlog (i.e. tasks) while continuing to estimate the product backlog using points. I don't see any great problem with doing that.

Time-tracking on top of (guess)timation ... when this team is supposed to work? Personally I do see a great problem with doing this. As an Adviser, Scrum Master or Manager you may buy it because you won't be wasting your personal time, but the team won't be happy about it.

---

To the original question. From a financial standpoint, it makes total sense to charge for fully-loaded costs, including management and process overheads such as Scrum ceremonies. Somebody should pay a salary to them.

From an operational standpoint, tracking ceremonies look like an additional overhead that does not add any value and deteriorates team morale as we can see in your post. The company already is "paying" for the first-order overhead of Scrum and then another round of second-order overhead to track it, to ultimately transfer it to the customer :)

While there is a number of reasons why it is a good or bad idea and how granular you want to go, there is a compromise -- a Jira app for automated time-tracking that does not require manual logging and can handle "overheads" without tickets. You will need to learn a little bit more about Kanban though.