What a passing acceptance test and an unexpected gap in Linear taught me about the distance between working software and a team that knows where the work stands.
At the end of Part 6, When the Rhythm Meets Reality, I wrote that I was beginning to understand how to lead the work happening within the Final Mile.
That felt like progress. And it was.
I was becoming more comfortable making decisions about requirements, scope, testing, and how separate pieces of work needed to come together. The challenge was no longer just getting through an episode. It was making sure we delivered the right thing.
Then I ran into a different kind of problem.
The application was working. The acceptance result was green. My XO had the evidence to show what had changed.
But the tracking board did not get the memo.
Apparently, finishing the work and making sure everyone knows it is finished are not always the same episode.
The Test Passed. The Board Didn’t Move.
The experience started with a defect involving the Monitor Diagnose dialog. An earlier problem had caused the diagnostic view to crash instead of displaying the information it was supposed to show.
The XO worked through the fix. The updated application was available in our Development environment. We then ran acceptance checks against the real behavior, not a mocked screen standing in for it.
The result was a Development PASS.
The diagnostic dialog opened. The failure we set out to correct was no longer occurring in that verified path. We had a result that could be inspected and a report explaining what had been tested.
So I expected the next step to be straightforward. We had connected our workflow to Linear and established instructions for automatic issue intake and lifecycle updates. Once the acceptance result was recorded, the related issue should have reflected the appropriate progress.
When I checked, that automatic update had not happened as expected.
Wait. What?
I had been so focused on proving the application worked that I had assumed the coordination around that work would follow along. The code had moved forward. The test evidence had moved forward. The board had not kept pace.
It was not evidence that the fix had failed. It was evidence that another handoff needed attention.
There Is More Than One Kind of “Done”
This is where the distinction started to matter to me.
A feature can be implemented without being tested. It can pass acceptance in Development without being released to Production. It can be verified technically while the issue tracking that work still shows an earlier stage.
Those are different facts, even when they all describe the same change.
A green acceptance report answers a specific question: did the expected behavior pass the checks we ran in the environment we named?
The issue board answers a different one: where does this work stand in the team’s agreed process?
One does not automatically answer the other.
And if I am not careful, a status can be just as misleading when it moves too quickly as when it never moves at all. Marking something complete before the required verification or review tells people more than the evidence actually supports.
That is a problem, especially when someone else is relying on that status to decide what to test, review, or pick up next.
A Fix Does Not Automatically Close Every Related Issue
There was another wrinkle. The Monitor Diagnose work was connected to earlier checks and related issues, and not all of those checks had reached the same acceptance point.
Some had documented limitations. Others still needed specific verification before anyone could call them an unqualified PASS.
It would have been convenient to look at the latest successful result and say, “Great. Everything connected to this is done too.”
Convenient, yes. Correct, not necessarily.
Fixing the defect that blocked a journey does not, by itself, prove that the entire journey has been rerun successfully. Just because one screen now behaves correctly does not mean every role, permission boundary, or downstream path has been checked.
This felt a lot like the requirement decisions I described in Part 6. The important question was not how many issues we could move across the board. It was which issues had actually earned that move.
That is the kind of decision I want the XO to help execute, not make up on my behalf.
Teaching the XO the Last Handoff
We had already taken steps to make Linear part of the process. There were rules describing automatic issue creation, lifecycle updates, and how engineering documentation should connect to the work.
I liked the idea immediately. The XO was already helping manage episodes, tests, reports, and commits. Why should I have to manually reconstruct the story in a separate tracking system every time?
But writing a rule and seeing the rule execute correctly are two different things.
When the expected update did not occur, the answer was not to assume the issue was synchronized just because the instruction existed. I needed to look at the actual handoff. Was the right issue linked? Had the update been invoked? Did the expected status match the evidence and the board’s workflow?
I also needed to resist an easy shortcut: asking the XO to mark everything related as complete simply to make the board look tidy.
The goal was not a prettier board. It was a trustworthy one.
I did not need to pretend I knew the technical reason for the missed automatic update before tracing it. What mattered was identifying the gap, inspecting the evidence, and making sure the record reflected only what we could support.
Why the Board Matters More as the Work Grows
In Part 6, I talked about managing multiple branches and worktrees. Different pieces of work could move forward separately, but they still had to come together without losing track of what belonged where.
That same problem exists beyond Git.
A developer or XO may know a fix has been committed. A tester may know it passed in Development. A teammate reviewing the next task may only see what Linear says.
If those views disagree, people are left reconstructing the truth through messages, commits, deployment records, and acceptance reports.
I know from my Business Analyst experience how quickly that can become frustrating.
The board should not replace the evidence. It should point people to the evidence and communicate the current state accurately. That is what makes it useful for coordination instead of just another place to update a status.
As more work happens in parallel, that visibility becomes less of a convenience and more of a necessity.
Adding One More Check to the Rhythm
I am not interested in turning the Final Mile into a process where I spend more time updating tools than delivering software.
That is exactly the kind of repetitive work I want the XO to help with.
What I am learning is that the rhythm needs one more deliberate check: before I treat an episode as closed, I should be able to follow the work from the issue to the implementation, from the implementation to the acceptance evidence, and from that evidence back to an accurate issue status.
If the test passed in Development, say Development. If a related check still has a limitation, record the limitation. If the board was supposed to update automatically, verify that it did.
None of that makes the feature better by itself. But it makes the work easier to trust, hand off, and build on.
And that matters when the next episode starts.
Closing the Loop
Part 6 made me think harder about whether we were solving the right problem. This experience added a question I had not been giving enough attention:
Can someone else tell what we actually finished?
The XO can execute the change. Playwright and acceptance checks can help prove the behavior. Git can preserve what was committed. Linear can communicate where the work stands.
But those pieces only tell a useful story when they agree.
I still want the green tests. I still want the successful deployment. And I absolutely still want to hear “Roll Credits.”
I just want the next person who opens the issue to understand why we rolled them.
The Final Mile is teaching me that leading the work is not only about getting to the correct result. It is also about making that result visible, traceable, and ready for the people who come next.
And the journey continues.
Until the next episode.
Notice: All product names are property of their respective owners. Company, product, and service names appear for identification purposes only.