In this chapter
I look at number of completed tasks, time for a change to reach production, and delivery of roadmap goals. People have individual goals and a quarterly responsibility scope. I want to know what we delivered and what still stops us.
Below, I suggest how to check this in your own project. Open the current plan, tasks and recent releases. Use them for the review.
Collect the result from your project
| What to check | What to open and record |
|---|---|
| What did we deliver? | Roadmap goal, quarterly responsibility, and a working result. For the goal, state what is done and what remains. |
| How long did it take to reach production? | Date the task entered the measured process and confirmed deployment; alongside it show unreleased changes and their waiting time. |
| How much did we finish? | Number of accepted tasks in compared periods. Separate new features, fixes, and maintenance; mark changes already in production. |
| How much returned for correction? | Tasks with confirmed defects, post-release problems, and repair time. Record what failed and its user impact. |
| Do people use agents? | How many team members used an agent in a real task and for what. Show an accepted result and one that needed correction or rejection. |
Before counting, define what “entry” means for you. Do not substitute deployment date with acceptance or code-merge date. Check tasks that do not need production by their agreed result.
Compare similar work before and after the change
Take two equal periods. Count completed tasks and time to production. Do not count subtasks twice. Mark changes in task size, team composition, and availability. Missing history? Start collecting it today.
Record the number of compared tasks and longest-waiting changes next to the result. Observe defects for the same time after release: a recent change may not yet have shown a problem. Missing data are not zero. If you also changed scope or the way of working, do not attribute the whole difference to the agent.
Check that faster still means good
For comparison, include test and review results for the released version. For a change involving user data, check:
- Can one person see or alter another person’s data without permission?
- Do new code or files contain passwords or keys?
- Do used libraries have detected, material security problems?
- Was a reported defect repaired and checked again?
Each check needs a result and evidence. “The agent accepted it” or “nobody reported a defect” is not enough. Choose other checks for the change; these four questions do not cover all application security. Resolve a serious, confirmed problem before release.
The result should lead to one concrete change
| What you see | What to do next |
|---|---|
| Code is created faster but waits for review | Open the oldest waiting change. Agree who checks it and what they need from the author. |
| The agent repeatedly asks for the same rule | Complete the right description and check in the next task whether the agent can use it. |
| Number of corrections grows | Take the latest defect, reproduce it, and add a check that catches it before the next release. |
| More tasks are done but the roadmap goal is stationary | Return to the missing result. Agree what you finish, who leads it, and what you defer. |
| Only part of the team works effectively with the agent | Have them show others one real task: instruction, result, corrections, and check method. |
For us, this is internal-team work. If you bill a client, after the first delivered slice compare planned time and cost with actual time and cost, including tests and corrections. Update remaining scope, date, and amount for agreement with the client. Using AI alone does not determine a price.
Download templates and review them with an agent
Download · Text fileReview of work with AI — card to completeteam-ai-transition-en.mdDownloadDownload · Text fileRoadmap and quarterly goals — team and individual document templatesteam-cele-i-roadmapa-en.mdDownloadAttach the needed file to the project conversation and state which data the agent may access. The goals template helps connect the result to the roadmap and a person’s responsibility. The review card collects numbers, problems, and the next decision.
Review our plan, tasks, and releases from [before] and [after]: [sources]. Check whether we can compare them. Ask for the definition of entry into measurement. Show completed tasks, time to confirmed production, changes still unreleased, corrections, and roadmap-goal results. Include quarterly responsibilities, team availability, and evidence of quality and security checks. For numbers give the source and observation count. Do not turn gaps into zeroes. Identify where the agent helped and where we still wait or correct its work. Do not attribute the whole difference to AI or judge people by task count. Propose one change: what we do, who takes it, and in which task we will check the result. Show the proposal for agreement without writing to services.
After the review, one decision to apply in work, an accountable person, and a date to check the result should remain.
End of the main path
Apply your chosen change to the next task and review the measurements on the agreed date.
Optional: MiddleBrain — from my workshop