A Cameraman Asked Me for a “Simple” App. Ninety Minutes Later, I Understood Why Your Backlog Keeps Lying to You

My phone rang on an ordinary afternoon. It was Vladimir, a friend of mine, a cameraman who has spent his career framing other people’s stories through a lens.

“Dejan, I need a simple application. A shift schedule. Nothing complicated. A table, a few workers, who works when. Can you make that for me?”

I was at my desk. I had a blank document open and a coffee going cold next to the keyboard. And I remember exactly what I thought: easy. An afternoon of work. A table with names down one side, the days of the week across the top, done by dinner. A phone would almost be enough to sketch it out.

So I said what I always say. Okay. Tell me what you need.

That was the moment the floor quietly opened up beneath me.

Ninety minutes later, that “simple” request had unfolded into a whole system of hidden questions I had been asking on instinct for years without ever naming them. Naming them is what eventually turned into the framework I now use with AI to take a vague request and produce a sprint-ready story in about ten minutes. But I am getting ahead of myself. First, the phone call.

“There are 27 of us, and everyone wants the second shift”

We sat down. Vladimir talked, I took notes. He explained, I asked a question. He answered, and his answer raised two more. An hour and a half later I was looking at a page that had nothing to do with the afternoon I had imagined.

It started innocently. “There are 27 of us. The problem is everybody wants the second shift. We need an app to solve that.”

Sounds like a table, right? But software does not understand “everybody wants.” So I started asking.

How many people have to be in the first shift for the crew to function at all? How many are allowed in the second? If there are four spots in the second shift and five people apply, do we take the fifth, or is four a hard limit? You have 27 workers but a single day only needs 15 across both shifts. What do the other 12 do?

Then it got deeper. Vladimir told me about a rule he carried in his head but had never written down. He called it greed and modesty. A cameraman who asks for the second shift every single day of the week is being greedy. A cameraman who asks for the second shift only on the one day he genuinely needs it is being modest. The whole point of the app, he said, was to reward the modest and quietly discourage the greedy.

Beautiful. Human. And completely undefined.

Because the second I tried to turn that into a rule a computer could follow, the questions multiplied. Two modest workers want the same day and only one spot is left. Who wins? When a modest worker bumps a greedy one out of a full quota, what happens to the person who got bumped? Do we tell them? Do they drop to the first shift automatically? Is priority calculated for each day on its own, or for the whole week at once? The weekend ran on entirely different logic, where someone might say “I want the day off, but if I cannot have it, give me the first shift.” And the entry window only opened on Friday from eight to noon, which raised its own swarm: what if someone starts filling it in and does not finish, what if they never fill it in, what if Friday is a holiday.

Each of those questions was a knot. And every knot had to be untied before a single line of code got written, because if I did not untie them, the programmer would, in his own way, and it would not match anything Vladimir had pictured.

Somewhere in that hour and a half, Vladimir went quiet, looked at the page, and said the sentence that is the whole reason I am telling you this. “This actually isn’t a simple application.”

The gap I kept falling into, and you probably do too

Here is the part where you might recognize yourself.

Vladimir did nothing wrong. He is an expert. He had a real problem and a legitimate idea. In his head, the solution was obvious, because he already knew all the context. The trouble is that the context living inside someone’s head and the context that has to be translated into working software are two completely different worlds.

If you are a Product Owner or a Scrum Master, you live in that gap for a living. A stakeholder hands you a single sentence. “We need a way for users to manage their notifications.” It sounds like a table with names. You write it up as a tidy little story, it goes into the backlog, the team picks it up, and then in sprint review you discover the dozen decisions nobody made. Greed and modesty, in some form, was hiding in there the whole time. The request was never simple. It was just unexamined.

What I wanted that day, and what I suspect you want too, was not to be cleverer than everyone in the room. I wanted to sit across from a person with an idea in their head and reliably, repeatably pull out a specification that was actually ready to build. Without three rounds of “wait, what about.” Without ambiguity leaking into the backlog and surfacing two weeks too late. I wanted “simple” to actually become simple, and I wanted it to be fast.

What I actually did, and the pattern I could not stop seeing

So I did the slow thing. I went back to Vladimir with a second round of questions, the ones that only appear once you try to write the first answers down into a consistent document. The weekend combinations showed up there. The exact mechanics of the displacement rule, where a modest worker automatically kicks a greedy one out of a filled quota, crystallized only when we walked through each scenario by hand. In the end there was a functional requirement, version 2.0, twelve sections, covering the priority algorithm, the quotas, the edge cases, the user roles, all of it. From a “simple phone call” to a small business system with its own rules and exceptions, and we still had not written one line of code.

And as I read that document back, something clicked. The value had not come from me being brilliant. It came from the questions. The same families of questions, every single time, across every project I had ever touched. What are the limits. What happens at the edges. Who has permission to do what. What if two rules collide. What did the person assume without saying it out loud.

That was not talent. That was a pattern. And anything that is a pattern can be turned into a system.

The thing I believe now

Here is my “I believe” statement, the one this whole story has been walking toward.

I believe the bottleneck in product work today is not a lack of AI. Everyone has AI now. The bottleneck is that people paste a vague, one-line request into a chatbot and are surprised when they get vague, one-line thinking back out. Garbage in, garbage out. The model did not fail them. The prompt did.

The skill was never the AI. The skill is the structure you bring to it. And the structure is exactly the thing I had been doing by instinct with Vladimir for an hour and a half: inject the real context, capture the raw request word for word, ask for a usable structure, force the edge cases into the open, then test and validate what comes back against reality.

I gave it a name so I would stop relying on instinct and start relying on a process. C.R.A.F.T. Context Injection. Raw Request Capture. Ask for Structure. Force Edge Cases. Test and Validate. Five steps. It is, quite literally, the Vladimir conversation turned into something I can run on purpose, every time, with AI doing the heavy lifting and me steering.

“Force Edge Cases” is the part that still makes me smile, because it is the step that would have caught the holiday Friday, the unfinished entry, the bumped worker with no notification. All the things that used to ambush me in sprint review now get dragged into the light before a developer ever sits down.

Let me show you what that one step alone does. Take the request exactly as Vladimir gave it to me.

Raw request: “Build a simple shift scheduling app.”

Force edge cases: What happens if five people want the four available spots? What happens if nobody submits their schedule before the window closes? What happens if Friday, the only day the schedule opens, lands on a holiday?

Three questions. Maybe sixty seconds of thinking. And we just surfaced three requirements that were completely invisible inside the word “simple”: a quota rule, a fallback for empty submissions, and a calendar exception. Multiply that by the four other steps and you stop guessing at what a stakeholder meant. You know.

That is the entire difference, and you just watched it happen in one paragraph.

What changed

Here is the number that matters.

That original conversation with Vladimir took more than ninety minutes, and a second round of questions on top of it.

Today I can take the same kind of request and produce a sprint-ready story in about ten minutes.

Not because the requests got simpler. They never do. Because the process became repeatable. The framework forces the same edge cases I used to surface by feel, in a fraction of the time. Complex requests still get a quick decomposition step first, but each story inside them lands in roughly ten minutes, ready to build.

The backlog stopped being a graveyard of half-thought tickets that detonate later. Sprint review stopped being the place where I find out what I forgot to ask. And the conversation with the stakeholder got better, not worse, because I show up with sharp questions instead of a blank page.

That is the difference between a request and a requirement. And it is learnable.

If this story felt familiar, try this

For ten years I have taught Scrum, and more than 140,000 students have come through my courses. Across all of them I kept seeing the same thing once AI entered the picture. The AI was almost never the problem. The inputs were. People brought vague requests to a powerful tool and got vague answers back, then blamed the tool.

C.R.A.F.T. did not come off a whiteboard. It came off a real project, a real friend, and a real “simple” app that turned out to be anything but. That is the version I trust, because it survived contact with reality first.

So before anything else, try the smallest possible version yourself. Take one item from your current sprint backlog, the one that looks tidy and harmless, and ask it the same questions Vladimir’s app forced out of me:

• What are the limits?
• What happens at the edges?
• What did someone assume without saying it out loud?

You will find something hiding in there. You always do.

If you want the complete C.R.A.F.T. process I use to do this systematically with AI, from the first vague sentence to a finished specification, that is exactly what I teach inside the AI-Powered Backlog Refiner. The real Moj Raspored case, Vladimir, the 27 cameramen, the greed and modesty rule, the displacement algorithm, the Friday window, threads through the entire course, so you never watch the framework work on an invented example. You watch it work on this one.

The next time someone tells you they need something “simple,” you will not feel the floor open up. You will reach for a process.

Start here: whatisscrum.org/ai-powered-backlog-refiner

– Dejan Majkić