rePlan - the idea and the mechanics
rePlan isn't a plugin. It's not another tool. It's a mental shift - and a physically simple grid.
Rows: people. Each team member, one row. Columns: sprint days. Day 1 through 10 (assuming a two-week sprint). Cells: what this person is doing that day, what they're waiting on, what's blocking them.
You draw it on a whiteboard. Or in Miro. Or in Excel. The format doesn't matter. The content does.
How does it work in practice? You start Sprint Planning with Jira - what needs to be done, as always. Then you take rePlan and ask: "OK, so now - who, when, and in what order?"
And that's when things get interesting.
After ten minutes with the grid, you see things you wouldn't spot in Jira over two weeks.
What I discovered in the first week of using it
Discovery one: Janek is doing this alone for eight days.
A backend feature that was supposed to take "maybe two or three days." When I drew the grid, I saw that Janek had eight of the sprint's ten days planned for that one story. Nobody saw this in Jira, because there was one task - "Implement payment gateway." One task, eight days, one person.
I asked: "Janek, do you need help?" Silence. Then: "Well... it might help, I've got a blocker in the integration with the external API."
We knew a week early. We could react a week early.
Discovery two: Kasia is waiting on an API until Thursday.
The frontend developer depends on a backend endpoint. Endpoint ready on Thursday. Frontend can start on Friday. Sprint ends on Friday.
In Jira: everything green. Backend "In Progress," frontend "To Do" - nothing alarming. In the rePlan grid: Kasia has three working days for work that realistically requires five.
Discovery three: two people are writing the same thing.
In one sprint, when I drew the grid, I saw that Marek and Agnieszka both had work planned on the same component. Different tasks. Same class. Nobody had talked about it at Sprint Planning because in Jira they were two separate tickets.
A three-minute conversation saved two days of work.
How to implement it starting tomorrow - step by step
When to run rePlan: immediately after Sprint Planning. Before people return to their desks. While you still have everyone in the same room.
How long does it take: fifteen to thirty minutes. No more - in most cases. If it regularly runs longer even with well-prepared Sprint Planning - that may be a signal that the team has too many external dependencies or too many parallel threads in flight. That is also valuable information.
Step 1: Draw the grid. Rows = people, columns = days. You can use a whiteboard, an A3 sheet, Miro, Google Sheets.
Step 2: For each story in the sprint, ask: "Who's doing this? When do they start? What does it depend on? What needs to be ready before this?" Fill in the grid.
Step 3: Look for signals: one person overloaded? Someone waiting on someone else? Two people in the same place? Those are the conversations to have right now.
Step 4: At the start of each sprint day - five minutes with the grid. "What changed? Has anyone's plan shifted?" Not as control - as synchronization.
How to respond to gaps you find: don't panic. A gap found on Monday is an opportunity. A gap found on Thursday is a problem. The whole point of rePlan is earlier detection.
Results from the case study - 16 teams, three months
I implemented rePlan as part of a larger GBS transformation - the same one I describe in my articles on ADKAR and change management. Sixteen teams. Three months as the phase in which rePlan was the primary synchronization tool.
Time to Market down 35%.
The disappearance of the phrase "I did my part" - that's not a hard metric. I tracked this through individual conversations with Scrum Masters and in retrospectives - each of them identified it as a noticeable shift in language and attitude, not just process surface.
"A swarm instead of individuals" - that's how one of the team leads described it. Instead of eight people working in parallel with no contact, they started working like one organism.
Context: this was a GBS transformation, a service environment, under strong time pressure. Your conditions may differ. The mechanism is the same.
The one thing rePlan won't replace
rePlan shows the plan. It doesn't replace conversation.
The grid is a tool for triggering conversations that otherwise never happen. Conversations about dependencies. About blockers. About the fact that someone needs help and won't admit it until someone asks directly.
One caveat for distributed or remote teams: the physical grid on a whiteboard works best when everyone is in the same room. For remote work - the same exercise in Miro or Google Sheets gives a similar result, as long as you remember one thing: do it together, live, not asynchronously. rePlan without a shared moment is just another spreadsheet.
The tool is simple. The conversations can be hard.
But that's a good kind of hard. Better than a fire on Thursday.
Do you trust your Jira mid-sprint? Or put differently - when did you last check whether what's "In Progress" is actually progressing the way you think it is?