Shake Up: Our Own Sprint Method
This is the story of how we adapted Shape Up and what we learned about optimism, focus, and iteration.
TL; DR
Clarity beats completion. Even when we missed deadlines, staying aligned on what we were building made the difference.
A simple artifact drives focus. One shared table, updated consistently, kept nine people on the same page.
Optimism isn’t the enemy. If your team consistently underestimates timelines but still ships, the problem might not be the estimates—it might be elsewhere.
Borrow what works. We started with Shape Up, renamed it, adjusted it, and we’ll keep evolving it by learning from other methods.
Automate the noise. Status updates and progress tracking are necessary but shouldn’t require manual effort every week.
How did we get here?
In early 2025, we at Talent started losing clarity. We were moving fast -experimenting, shipping, iterating - but alignment was slipping. We had quarterly plans, but when it came to weekly and daily execution, we struggled to stay on the same page.
We needed something simple: a shared view everyone could look at, understand the same way, and use to stay focused and accountable.
How we roll?
The Talent team doesn’t work with long-term roadmaps or annual strategic plans. We prioritize short cycles. We experiment, learn what works, and keep going. We’re good at staying close to what’s happening around us, moving quickly, and being open to trying new things.
But there’s a downside to speed. When you’re always pushing to get the next thing live, clarity gets harder to maintain.
Why me?
Our CEO Pedro suggested I take this on. Our CPO Filipe shared a video about Shape Up; the method Ryan Singer developed at Basecamp over years of practice. That’s where this started.
I watched the video. I skimmed their handbook, didn’t dive into every detail. On April 28, 2025, we ran our first sprint (Shape Up calls it a “timebox”).
What is Shake Up?
Here’s what I kept typing wrong: “Shake Up” instead of “Shape Up.” Eventually I realized we’d changed the method enough that renaming it made sense and I’d stop making typos.
Here’s the first definition I shared with the team:
Our Method: Shake Up
Goal: Make sure all deliverables are completed by their deadlines.
Timebox: Generally 2 weeks.
Workshop (before the timebox starts):
Define deliverables with tech and product.
Everyone commits to scope and deadline.
Engineers know exactly what to deliver.
Key input from tech: Which questions need answers during the workshop?
No flexibility during the timebox. We only focus on these deliverables.
Next (Break Week):
1 week break.
Workshop for the next timebox.
Handle pending small requests.
First Day
I ran the first workshop. At the end, I documented four deliverables in a Notion table: Delivery, Scope, Owner.
Two weeks later, we hadn’t completed any of them. You can imagine the atmosphere on that call. But we gained something critical: clarity. During those two weeks, focus didn’t scatter. The team knew what we were working on. We were on the same page.
A 90-minute workshop and one Notion page made that happen. Worth celebrating.
What changed as we ran more cycles
By the end of 2025, we completed eleven timeboxes; most two weeks, occasionally three. Our Notion table evolved. The final version: Deliverable, Scope, Outcome, Owner, Contributors.
We added:
Post-mortems after each timebox.
Opening workshops to the whole team (we’re nine people total).
A pattern we couldn’t ignore
Before Talent, I worked at a design-focused startup. I learned that designers tend toward optimism. At Talent, I learned product people and developers share the same trait.
Scoping a deliverable to actually finish within two weeks? Nearly impossible. Almost every time, the team uses the break week to finish what we committed to. After eleven timeboxes, our completion rate during the timebox itself would probably be around 50%, if we didn’t count work done in break weeks.
The old version of me would have seen this optimism as a problem. Now I see it as a character trait many people share. Because ultimately, we do ship most of what we commit to (even if it bleeds into break week).
I don’t see myself saying: “In the original method, incomplete tasks get dropped and don’t get worked on until they’re added back in a workshop. We’re going to do that too.” Sure, I won’t push hard on this; but is there really nothing else to improve? Of course there is.
What’s next: Shake Up V2
1. Borrowing from other methods
One of our developers, Panos, has been in this field for years and has experience with many approaches. Two months ago we sat down and he walked me through Scrum and Kanban. I took notes, asked questions, and thanked him, saying: “You’ve given me a lot to think about.” I wasn’t just being polite and I’ll be going back to those notes soon.
2. Let AI do some of the work
Our current flow:
After the workshop, I compile everything into our Notion deliverables table.
Updates and questions happen in Slack.
Code changes, commits, and PRs happen in GitHub.
On top of this, the team writes and presents weekly updates.
It’s time to let AI handle that last part. I’ll start inside Notion, building a semi-automated system with Notion AI. Then I’ll use the vibe coding skills I’ve been developing over the past year to build a simple Shake Up dashboard myself.
You’ll hear more when Shake Up V2 is live.
Stay curious.
Tolga