Live Testing and Triage: Feeding Real Feedback Into the Sprint

Sprint 1 shipped, Sprint 2 was groomed, and every test was green. So I stopped writing code and used the product. I opened the app on localhost and clicked through it the way a customer at the bar would. Within minutes I had three problems that no planning document had surfaced: the login screen has no social sign-in, creating an account fails with no explanation, and the landing page looks like a placeholder because it is one.

This post is about what happened next. Not the fixes. The triage.

Testing the product is not the same as testing the code

The project runs a real CI gate. Every push runs the backend and frontend suites, and the definition of done requires tests with every story. All of that held. The pipeline was green while registration was broken for any normal person.

The gap was not a missing test run. It was a missing question. Every auth test registers with the password Passw0rd!, which happens to satisfy ASP.NET Identity's default complexity rules. Nobody ever asked what happens when someone types beer1234. The answer: the API rejects it with a helpful message, the frontend throws that message away, and the user sees "Registration failed" with no clue why. Two small defects that only line up when a real person is typing.

CI verifies what you thought to encode. Using the product finds the questions you never thought to ask. You need both.

Three issues, three different triage outcomes

The point of a backlog is that not everything new is equally urgent. Each finding got a different treatment, on purpose.

• The registration failure became a bug and jumped the queue. It is a defect against shipped work, not new scope. It also blocks everything: every Sprint 2 story needs test accounts, and right now creating one fails unless you happen to guess the password rules. So it went into the open sprint as an interrupt, first in the working order. This was also the moment the project got a written bug convention, because it had never needed one before. Now the rule exists: bugs get the bug label plus their owning epic, and blockers interrupt the open sprint.
• The landing page became a story, scoped deliberately small. The full home-screen redesign already lives in a planned sprint, and pulling all of it forward would blow up Sprint 2. Instead the interrupt covers the minimum: adopt Tailwind as the styling foundation, turn the placeholder route into a real Home page, and make the shell presentable. The redesign stays where it was planned.
• Social sign-in got no ticket at all. It is already on the roadmap as its own future sprint, researched and written down. Ticketing it now would just duplicate the plan. The only change was a note that live testing confirmed the gap.

One session, three findings, three different answers. That is what triage means.

The PM angle

Two things I want to keep from this session.

First, schedule the dogfooding. I found these problems because Sprint 1 had just closed and I had a natural pause. That was luck. The lesson is to make it deliberate: after every sprint closes, use the product like a customer before grooming the next one. It cost twenty minutes and reshaped the top of the backlog.

Second, protect the sprint while honoring the feedback. The tempting move was to start restyling the whole app, because ugly screens are visible and satisfying to fix. The discipline was writing down exactly one small interrupt for it and leaving the rest in its planned sprint. Feedback should update the plan, not dissolve it.

Where the project stands

Sprint 2 now has seven items: the five groomed stories plus the two interrupts. The landing page facelift shipped today on its own branch with tests written first, including a compatibility layer so Tailwind's CSS reset does not break the pages that have not been restyled yet. The registration bug is next, and its fix will include the test that was always missing: one that tries to sign up with a password a real person would actually pick.