Do you know that feeling? Sprint Planning ends. The team has "committed" to the goal. In Jira (or Azure DevOps), everything glows blue in the "To Do" column. It looks like a plan. But is it really?
What you actually have is a wish list. Jira answers the WHAT very well. But it stays silent on HOW, WHEN, and WITH WHOM.
For years working as a Scrum Master, Agile Coach, and Enterprise Transformation Coach in large organisations, from telecoms to banking, I kept seeing the same pattern: competency silos, the "I did my part, now you deal with yours" effect, and panic in the last two days of the sprint.
That is why I created rePlan. A tool that is simple in structure but revolutionary in effect. It is not another plugin. It is a mental shift.
What is rePlan?
Imagine a simple grid.
- Rows: your people. Janek, Kasia, Bartek, Zosia.
- Columns: the days of the Sprint. Monday, Tuesday... all the way to Review.
This is not a Gantt chart created by a manager and imposed on the team. It is a game board that the team fills in itself. During planning, we add:
- Availability: holidays, training, doctor visits, real capacity.
- Work over time: lines showing when we plan to work on a given story.
- Dependencies: if Kasia needs code from Janek, her task cannot start before Janek's task is done.
Sounds simple? The power is in what happens later.
Effect 1: The death of the Hero and the birth of the Swarm
In the traditional approach, a developer takes a task and disappears for three days. On rePlan, that shows up as a long, lonely line. The team sees it immediately: "Hey, Marek, you are carrying this giant task all by yourself for half the sprint. What if you get sick? What if you get stuck?"
rePlan naturally encourages swarming. Instead of one long line, the team starts drawing two or three shorter, parallel lines for the same topic.
Gain: knowledge is not trapped in one person's head, and tasks get finished faster.
Effect 2: Daily Scrum stops being a confession
Most Daily Scrums are status meetings: "Yesterday I did X, today I will do Y." Boring. And a waste of time.
With rePlan, Daily becomes a tactical briefing. We look at the board:
- "We were supposed to finish this module yesterday and it is still going today. The line is moving to the right. What does that mean for the rest of the sprint?"
- "I can see that Zosia has training tomorrow and Bartek is waiting for her code review. We have a bottleneck. Who else can check it?"
The discussion moves away from the past ("what I did") and toward the future and risk management ("will we make it?").
Effect 3: The end of the testing squeeze
Classic problem: developers code for eight days of the sprint, and testers have two days to check everything. In Jira you do not see it until tasks land in the "Ready for Test" column.
On rePlan, you see it in seconds during planning. If the developer lines are full until Thursday and the tester lines are empty at the beginning of the sprint but overloaded at the end, the board is screaming that the plan is unrealistic.
That forces earlier involvement of testers or breaking stories down so they can start testing on day two or three of the sprint.
It also helps the team move into a way of working where testers start defining how something will be tested as soon as work on that topic begins. As a result, all that is left at the end is executing an already defined test.
Case Study: Transformation in finance
As an Enterprise Agile Coach, I worked with a large tribe, around 16 teams, that was struggling with unpredictability and low engagement.
Situation BEFORE:\ Teams were delivering points, but not value. Solution integration was rare and painful. The split was clear: "We are the devs, you are the business."
Introducing rePlan:\ I introduced rePlan not as a control tool, but as a tool for aligning reality.
- At first there was resistance. "This is micromanagement!" "Drawing lines is a waste of time."
- The breakthrough came when one team noticed halfway through the sprint, thanks to the board, that they would not meet the goal because of the absence of a key architect. Instead of pretending everything was fine, they changed the scope during the sprint and informed the Product Owner.
- The sprint ended successfully because they delivered what mattered most, without overtime. Other teams noticed.
Results after 3 months:
- Time to Market (TTM) down by 35%: thanks to visualised dependencies, teams stopped blocking each other. Waiting time, the waste, was drastically reduced.
- Engagement up by 40%: people felt they had influence over the plan. This was not a manager's plan, it was their plan, built on their rules.
- A culture of planning with context: teams stopped planning around "closing tasks" and started planning around "achieving the goal" in a given time.
Scaling: rePlan at multiple-team level
The power of rePlan grows exponentially when we place several boards side by side, for example on a shared Miro board for an entire tribe.
If Team A is building an API for Team B, then in a regular planning session we hear: "We will deliver it this sprint." On an integrated rePlan you can see:
- Team A plans to finish the API on Friday.
- Team B plans to use that API on Wednesday.
The visualisation exposes the collision before the first line of code is written. That gives teams a chance to negotiate the order of work before the sprint starts, which is essential for building an integrated increment in large organisations.
Summary: From silos to collaboration
rePlan treats the hardest disease in Agile teams: loneliness in a crowd.
It breaks silos because it shows that an empty box in my row is an opportunity to help a colleague who is drowning in their own row.
It changes the story from "I did my task" to "We delivered our plan." And that is the whole point.