Software House: Sprints, Tickets and Billable Hours in One Place

Monday, nine in the morning. Client A's sprint is halfway done. Client B, whose system you delivered in March, calls because report generation stopped working in production. And at the end of the month, finance asks for everyone's hours to invoice. Three different routines, with different rhythms, and the temptation is to set up three tools: one for development, another for support, a spreadsheet for hours.

The result is usually the same: duplicated information, an urgent ticket nobody sees on the sprint board and hours logged from memory on Friday night. Here's a way to organize the three routines without three tools and without mixing what needs to stay separate.

The three routines and why they don't mix

Routine	Nature	Rhythm	Question it answers
Sprint	Planned work	One- to two-week cycles	What are we delivering this cycle?
Production ticket	Demand that arrives without warning	Continuous queue, with deadlines	Who handles it, and how fast?
Billable hour	Effort record	Monthly close	How much do we charge, and who?

A sprint is predictable; a ticket isn't. If you throw everything into the same queue, the urgent tramples the planned and the team never finishes a cycle. If you split them across different tools, you lose the big picture: nobody knows how much of the sprint was eaten up by support. The way forward is to keep the three routines distinct and in the same place.

Routine 1: the sprint

For planned development, the cycle remains the best instrument: an ordered backlog, a slice for two weeks, a burndown to see early whether things will get tight. The sprint in Tasskee brings together tasks from one or several projects, which matters for anyone serving multiple clients at once, and uses the velocity of previous cycles to plan the next one.

Reserve capacity for the unexpected

The most common mistake is planning the sprint at 100% capacity and then discovering that support consumes 20%. Look at how much time tickets have taken in recent weeks and leave that slice out of the plan. A team that reserves capacity for support doesn't have to blow up the sprint every time a client calls.

Fixed scope, open scope

On a fixed-scope project, the sprint helps the team organize itself and lets the client follow along. In an hour-bank or maintenance contract, the sprint becomes the way to distribute the contracted hours among improvements. In both cases the same rule applies: anything that enters mid-cycle requires taking something out that was already in.

Routine 2: the production ticket

A ticket has its own logic: someone reports, someone classifies, someone handles it, and there's a deadline. What it shouldn't be is a loose task on the sprint board, competing for attention with what was planned.

A setup that works:

• A dedicated queue for tickets, with their own statuses (new, under review, waiting on customer, being fixed, resolved) and deadlines by priority.
• A public intake form, so the client can describe the problem with the data you need: system, steps to reproduce, urgency. Fewer "it's not working" messages and more information you can act on.
• A triage rule. Every day, one person (it can be a rotation) looks at the queue before nine and classifies: is it a defect, a question or an improvement?
• Serious defects enter the cycle; improvements go to the backlog. A critical defect interrupts the sprint, with an explicit trade-off. An improvement requested through a ticket goes to the backlog and enters the next planning.

Tasskee's ticket queue has deadlines and SLAs by priority and the public intake form. Because tickets and tasks live in the same system, a defect that requires code turns into a development task without copying text between tools.

Routine 3: the billable hour

Here the rule is simple and harsh: an hour that isn't logged when it happens is almost never logged correctly. Logging on Friday night what was done on Tuesday is a guess, and a guess turns into an argument with the client.

Logging on the spot

Time tracking has to live on the task itself, one click away from where the person is working. No switching tools, no opening a spreadsheet. Each entry is tied to the project and the type of work, and that's what lets you bill differently: development at one rate, support at another, meetings at a third.

Hourly rate by project and type

A software house rarely has a single rate. The contract with client A might provide for R$ 180 per hour of development and R$ 120 for support; client B, a bank of 40 hours per month. With Tasskee's time tracking, the rate is set by project and type, the client statement comes out as PDF or CSV, and the invoice (nota fiscal) is recorded there, although issuing it continues to happen in your tax system, since Tasskee doesn't issue invoices.

Who gets paid by the hour

If part of the team is freelancers paid by the hour, the statement for whoever gets paid and the "My hours" screen avoid the "how many hours did I do again?" conversation. And since rate and cost have separate permissions, the person logging hours doesn't need to see how much the client pays.

How the three connect

The routines are distinct, but they share data, and that's where having everything in one place pays off.

1. A ticket becomes a task. The triaged defect enters the sprint or the day's queue, with a reference to the ticket.
2. A task receives hours. Whoever works on the defect logs the time right there.
3. Hours become an invoice. At closing, the report separates what was sprint, what was support and what was covered by contract.
4. The sprint knows about support. In the retrospective, the question "how much of the cycle went to tickets?" has an answer in hours, not in impressions.

An example week

A software house in Florianópolis, with eight people and four clients. Monday: planning a two-week sprint for two projects, with 30% of capacity reserved for support. Tuesday: a client opens a critical ticket through the form; the on-call person classifies it as a defect, converts it into a task and pulls it into the cycle, taking out a low-priority improvement. Wednesday to Friday: each person logs their hours on tasks, and the lead follows the burndown. Last business day of the month: finance exports each client's closing statement, with hours by type and amount, instead of collecting messages from the team.

What changes when an AI agent helps

Part of the management work in a software house is keeping requirements documentation up to date. In Tasskee, specs are documents tied to the project and to tasks, and they can be maintained by an AI agent through the MCP server: the agent that writes the code updates the spec, records decisions and tracks progress. That way the specification stops being a file that ages in a folder and starts reflecting what was done, with the tasks linked.

Mistakes that keep repeating

• Support inside the sprint backlog, with no reserve. The cycle blows up every two weeks.
• A ticket with no owner. A queue without daily triage becomes a graveyard of requests.
• Hours logged in batches. The bill reaches the client with no credibility.
• A single rate for everything. Development, support and meetings don't cost the same and shouldn't be billed the same.
• Mixing the on-call team with the sprint team without rotation. One person becomes "support" forever, and that's the one who quits.

Indicators that fit in a monthly meeting

With the three routines in the same system, the monthly management meeting can be short and based on four numbers: how much of the team's time went to sprint and how much to support; how many tickets were opened and how long they took to resolve; how many hours were billed per client; and how much of what was planned in sprints was actually delivered. The four answer different questions, but together they show whether the house is sustainable: if support eats more time than planned, it's time to review the contract or invest in fixing the cause of repeat tickets.

Where to start

Pick one routine at a time. If hours are the biggest leak, start there: logging on the task and monthly closing. If support gets in the way of development, start with the queue and the capacity reserve. Once all three are in one place, the Monday morning conversation changes: instead of putting out fires, the team knows what's planned, what's unexpected and how much each thing costs.