🚀 Sprint Tools Mudah untuk Pemula

Alat manajemen proyek yang sederhana dan praktis. Tidak perlu pengalaman teknis!

✓ Kalkulator Sprint ✓ Perencanaan Backlog ✓ Grafik Velocity ✓ Auto Save

📊 Dashboard Overview

Ringkasan lengkap semua data sprint Anda

🔍

🚀 ACTIVE

Total Sprint

⚡ AVG

Velocity Rata-rata

📋 TOTAL

Total User Stories

👥 TEAM

Anggota Tim

⚡ Quick Actions

📜 Recent Activity

✅

Sprint Planning Completed

2 hours ago

📝

5 User Stories Added

5 hours ago

🎯

Velocity Updated: 25 SP

1 day ago

🎓 Belajar Agile & Scrum

Panduan lengkap dari NOL sampai bisa praktik!

📚 BAB 1: Apa itu Agile & Scrum?

🔍 Bayangkan Skenario Ini...

Kamu diminta bos untuk bikin aplikasi e-commerce dalam 6 bulan.
Cara Lama (Waterfall): Kamu buat semua fitur selama 6 bulan, baru demo ke bos di akhir. Ternyata bos bilang "Ini bukan yang saya mau!" 😱

Cara Agile: Kamu bikin fitur paling penting dulu (login + keranjang) dalam 2 minggu, demo ke bos. Bos kasih feedback. Kamu perbaiki. Ulangi terus sampai sempurna. ✅

✨ Kesimpulan:

Agile = Kerja dalam siklus pendek, dapat feedback cepat, dan fleksibel terhadap perubahan.

🏗️ Scrum adalah Framework

Scrum adalah salah satu cara untuk menerapkan Agile. Seperti resep masakan, Scrum memberikan langkah-langkah jelas:

⏱️ Sprint: Periode kerja 1-4 minggu (biasanya 2 minggu)
👥 Tim: Product Owner, Scrum Master, Developer Team
📅 Event: Planning, Daily Standup, Review, Retrospective
📋 Artifact: Product Backlog, Sprint Backlog, Increment

👥 BAB 2: Siapa Aja Pemainnya? (Roles)

🎯

Product Owner (PO)

Tugasnya:

Tentukan fitur apa yang harus dibuat
Urutkan prioritas backlog
Terima/tolak hasil kerja tim
Jadi "suara customer"

Analogi: Seperti koki kepala yang tentukan menu apa yang harus dimasak.

🎓

Scrum Master

Tugasnya:

Fasilitasi meeting/event
Hilangkan hambatan tim
Jaga agar Scrum berjalan benar
Coaching tim

Analogi: Seperti pelatih sepak bola yang bantu tim main dengan baik, tapi bukan yang main.

💻

Development Team

Tugasnya:

Kerjakan tugas di sprint
Self-organizing (atur sendiri)
Cross-functional (bisa segala hal)
Deliver increment yang "Done"

Analogi: Seperti koki-koki yang masak sesuai menu, kolaborasi, dan hasilkan makanan enak.

📅 BAB 3: Event-Event dalam Scrum

🗓️

1. Sprint Planning

📋 Apa yang Dilakukan?

Tim kumpul di awal sprint
PO jelaskan priority backlog
Tim pilih tugas yang bisa diselesaikan
Buat Sprint Goal (tujuan sprint)

⏱️ Berapa Lama?

Maksimal 8 jam untuk sprint 1 bulan (biasanya 2-4 jam untuk sprint 2 minggu)

💡 Output:

Sprint Backlog (daftar tugas sprint ini)

☕

2. Daily Standup (Daily Scrum)

📋 Apa yang Dilakukan?

Setiap anggota tim jawab 3 pertanyaan:

Apa yang saya kerjakan kemarin?
Apa yang akan saya kerjakan hari ini?
Ada hambatan/blocker?

⏱️ Berapa Lama?

Maksimal 15 menit, biasanya sambil berdiri!

💡 Tujuan:

Sinkronisasi tim, cepat deteksi masalah

🎬

3. Sprint Review

📋 Apa yang Dilakukan?

Demo hasil kerja sprint ke stakeholder
Dapat feedback dari PO & customer
Diskusi apa yang sudah/belum selesai
Update Product Backlog jika perlu

⏱️ Berapa Lama?

Maksimal 4 jam untuk sprint 1 bulan

💡 Fokus:

PRODUK (apa yang dihasilkan)

🔍

4. Sprint Retrospective

📋 Apa yang Dilakukan?

Tim internal diskusi:

Apa yang berjalan baik? (Keep)
Apa yang kurang? (Problem)
Apa yang harus diperbaiki? (Try)

⏱️ Berapa Lama?

Maksimal 3 jam untuk sprint 1 bulan

💡 Fokus:

PROSES (cara kerja tim)

💼 BAB 4: Contoh Kasus Nyata

📱 Proyek: Aplikasi Toko Online "BelanjaKuy"

👨‍💼 Tim:

Product Owner: Pak Budi (pemilik toko)
Scrum Master: Mbak Sari (fasilitator)
Developer: Andi (Frontend), Citra (Backend), Dedi (Mobile)

📅 Sprint 1 (2 Minggu): Login & Katalog Produk

🗓️ Hari 1 - Sprint Planning:

Pak Budi: "Saya mau customer bisa login dan lihat produk dulu"
Tim diskusi, estimasi: Login = 5 SP, Katalog = 8 SP
Sprint Goal: "Customer bisa login dan browse produk"
Tim commit akan selesaikan 13 SP

☕ Hari 2-13 - Daily Standup (Contoh Hari ke-5):

Andi: "Kemarin UI login selesai. Hari ini integrasi API. Tidak ada blocker."
Citra: "Kemarin API login selesai. Hari ini buat API katalog. Butuh desain database dari Dedi."
Dedi: "OK, saya kasih sekarang. Kemarin setup database. Hari ini lanjut query optimization."
Mbak Sari: "OK tim, kalau ada blocker langsung ping ya!"

🎬 Hari 14 - Sprint Review:

Tim demo ke Pak Budi: "Ini Pak, customer sudah bisa login pakai email/password dan lihat 50 produk"
Pak Budi coba sendiri: "Wah bagus! Tapi loading katalog agak lama ya?"
Tim: "Noted Pak, kita tambahkan ke backlog untuk optimasi di sprint depan"
✅ Sprint Goal tercapai!

🔍 Hari 14 (sore) - Retrospective:

😊 Yang Bagus:

Daily standup efektif, cepat sync
Komunikasi tim bagus

😐 Yang Kurang:

Testing manual terlalu lama
Code review kadang tertunda

💡 Action Item Sprint Depan:

Setup automated testing (Andi lead)
Code review maksimal 2 jam setelah PR dibuat

📊 Hasil Sprint 1:

✅ Velocity: 13 SP selesai
✅ Product Increment: Login & Katalog (bisa digunakan)
✅ Feedback cepat dari Pak Budi
✅ Improvement untuk sprint berikutnya teridentifikasi

✅❌ BAB 5: Do's and Don'ts

✅ DO (Lakukan Ini)

✓ Sprint durasi tetap (time-boxed)
✓ Demo hasil setiap akhir sprint
✓ Daily standup maksimal 15 menit
✓ Tim commit sendiri capacity-nya
✓ Fokus selesaikan sedikit fitur dengan sempurna
✓ Retrospective jujur dan konstruktif
✓ Product Backlog selalu up-to-date
✓ Definition of Done (DoD) jelas
✓ Transparan tentang progress & blocker
✓ Adapt & improve setiap sprint

❌ DON'T (Jangan Lakukan)

✗ Ubah Sprint Backlog saat sprint berjalan
✗ Skip Daily Standup karena "sibuk"
✗ Daily standup jadi meeting panjang
✗ PO atau Manager assign tugas ke developer
✗ Banyak fitur setengah jadi (tidak "Done")
✗ Sprint Review cuma slide presentasi
✗ Retrospective jadi ajang blame
✗ Velocity dijadikan target KPI (ini indikator!)
✗ Sprint tanpa Sprint Goal yang jelas
✗ Scrum Master jadi "bos" tim

💡 BAB 6: Tips Praktis untuk Pemula

🚀 Untuk Tim Baru

1. Mulai sprint pendek (1 minggu) untuk adaptasi
2. Jangan over-commit di sprint pertama
3. Focus on learning bukan perfection
4. Gunakan tool sederhana dulu (Trello/Notion)
5. Celebrate small wins! 🎉

📏 Estimasi Story Point

Gunakan Fibonacci: 1, 2, 3, 5, 8, 13, 21
Jangan terlalu presisi (5 vs 8 OK, 5 vs 6 NO)
Pakai referensi: "Ini seperti fitur X kemarin"
Planning Poker bagus untuk diskusi tim
Lebih dari 13 SP? Pecah jadi lebih kecil!

🎯 Sprint Goal yang Baik

❌ Buruk: "Selesaikan 15 story"
❌ Buruk: "Kerja keras"
✅ Bagus: "Customer bisa checkout dan bayar"
✅ Bagus: "Admin bisa manage inventory produk"
Tips: Goal harus memberikan nilai bisnis!

🛠️ Tools yang Membantu

Backlog: Jira, Trello, Notion, ClickUp
Komunikasi: Slack, Teams, Discord
Retrospective: Miro, Mural, FunRetro
Estimasi: Planning Poker (scrum poker online)
Tracking: Burndown chart di tools above

🧮 BAB 7: Cara Menentukan Jumlah Sprint

🎯 Pertanyaan Penting

"Saya punya project e-commerce. Berapa sprint yang dibutuhkan?"

Ini pertanyaan yang sering muncul. Jawabannya ada di formula sederhana dan 3 pendekatan praktis.

🧮 Formula Dasar

Jumlah Sprint = Total Story Points ÷ Velocity Tim

Langkah 1: Hitung Total Story Points

• Breakdown project jadi user stories
• Estimate masing-masing story (pakai Rubrik SP di tab ini)
• Jumlahkan semua SP → Total SP Project

Langkah 2: Tentukan Velocity Tim

• Tim Baru: Pakai Calculator → estimasi velocity awal = 60-70% dari capacity
• Tim Existing: Pakai median velocity dari 3-5 sprint sebelumnya (cek tab Velocity)

Langkah 3: Hitung!

Contoh:

Total SP Project = 120 SP

Velocity Tim = 20 SP/sprint

Jumlah Sprint = 120 ÷ 20 = 6 sprint

(Dengan sprint 2 minggu = 3 bulan)

🗓️ Pendekatan 2: Time-Boxed (Ada Deadline)

Skenario: "Project harus selesai dalam 3 bulan!"

Langkah 1: Hitung Jumlah Sprint

Timeline = 3 bulan (12 minggu)

Durasi Sprint = 2 minggu

Jumlah Sprint = 12 ÷ 2 = 6 sprint

Langkah 2: Hitung Scope yang Realistis

Velocity Tim = 20 SP/sprint

Total SP yang bisa selesai = 20 × 6 = 120 SP

Langkah 3: Prioritaskan Fitur!

Pilih fitur paling penting yang total SP-nya ≤ 120 SP. Sisanya masuk backlog fase 2.

⚠️ WARNING:

Jangan paksa 150 SP masuk 6 sprint dengan velocity 20 SP. Hasilnya: overtime, burnout, quality jelek.

🚀 Pendekatan 3: MVP-First (Incremental Release)

Tidak harus semua fitur selesai sebelum launch. Bagi jadi fase:

📦 Fase 1: MVP (Minimum Viable Product)

Sprint 1-3: Fitur core yang HARUS ada

• Login/Register
• Product Catalog (basic)
• Shopping Cart
• Checkout dasar

Total: ~40-60 SP → 2-3 sprint → LAUNCH!

✨ Fase 2: Enhancement

Sprint 4-6: Fitur yang "nice to have"

• Review & Rating
• Wishlist
• Voucher/Promo
• Multiple payment methods

🎯 Fase 3: Advanced

Sprint 7+: Fitur advanced based on user feedback

• Recommendation Engine
• Loyalty Program
• Live Chat

💡 KEUNTUNGAN:

Launch cepat → dapat user feedback → iterate berdasarkan data real, bukan asumsi!

⚙️ Faktor Penyesuaian

Buffer 10-20%

Untuk bug fixing, technical debt, meeting tak terduga

Contoh: 6 sprint → tambah 1 sprint buffer = 7 sprint

Sprint 0 (Persiapan)

Setup environment, architecture, CI/CD pipeline

Tidak dihitung sebagai sprint delivery

📦

Release Strategy

Release per N sprint (misal tiap 3 sprint)

Sprint 1-3: Development → Sprint 3: Release & UAT

📉

Learning Curve

Sprint 1-2 velocity bisa lebih rendah (tim masih adaptasi)

Normal! Velocity akan stabil setelah 3-4 sprint

📊 Contoh Real: Project E-Commerce

Breakdown Story Points:

• Login/Register 8 SP

• Product Catalog (list, detail, search) 13 SP

• Shopping Cart (add, edit, remove) 13 SP

• Checkout Flow 21 SP

• Payment Gateway Integration 21 SP

• Order Management (history, tracking) 13 SP

• Admin Dashboard 21 SP

TOTAL 110 SP

Perhitungan Sprint:

Velocity Tim: 22 SP/sprint (dari data 3 sprint sebelumnya)

Durasi Sprint: 2 minggu

Jumlah Sprint = 110 ÷ 22 = 5 sprint

Timeline: 5 sprint × 2 minggu = 10 minggu (2.5 bulan)

📅 Sprint Planning:

Sprint 1-2 (MVP): Login + Catalog + Cart = 34 SP

Sprint 3: Checkout = 21 SP

Sprint 4: Payment = 21 SP

Sprint 5: Order Management + Admin = 34 SP → pecah jadi 2 sprint

Revisi: Butuh 6 sprint (termasuk buffer)

💡 Kesimpulan & Best Practices

✅ Formula dasar: Total SP ÷ Velocity = Jumlah Sprint
✅ Jangan over-commit! Velocity adalah kecepatan sustainable, bukan target maksimum
✅ Gunakan median velocity (lebih stabil daripada average)
✅ Tambahkan buffer 10-20% untuk hal tak terduga
✅ MVP first! Launch cepat lebih baik daripada sempurna terlambat
✅ Review & adjust setiap sprint. Velocity bisa berubah seiring waktu
✅ Breakdown story >13 SP jadi lebih kecil untuk estimasi lebih akurat

🌍 BAB 8: Agile Bukan Cuma untuk Software!

💡 Mitos yang Salah

❌ MITOS:

"Agile/Scrum itu cuma buat developer bikin aplikasi. Kalau saya kerja di marketing/event/construction, ga relevan."

✅ FAKTA:

Agile adalah mindset & framework kerja yang bisa diterapkan di berbagai industri! Prinsip dasarnya universal: kerja dalam iterasi pendek, feedback cepat, adaptif terhadap perubahan. Yang berubah hanya terminologi dan caranya saja.

🔄 Prinsip Universal Agile

1️⃣ Iterasi Pendek

Software: Sprint 2 minggu → deploy fitur baru

Marketing: Sprint 1 minggu → release campaign batch

Construction: Sprint 2 minggu → selesaikan 1 area (kamar, kitchen)

Event: Sprint 1 minggu → finalize 1 aspek (artist booking, stage design)

2️⃣ Feedback Loop Cepat

Software: Demo ke user → dapat feedback → iterate

Marketing: A/B test ads → lihat metrics → adjust strategy

Product: Sample test → user review → improve formula

Content: Upload episode → lihat engagement → adjust content

3️⃣ Prioritas & Fleksibilitas

Software: Backlog fitur → prioritize value tertinggi

Event: Task list → prioritize critical path (venue > artist > marketing)

Renovation: Scope work → prioritize urgent (atap bocor) dulu

Education: Module list → prioritize core concept dulu

📋 Adaptasi Terminologi per Industri

Istilah Scrum asli dari software development. Tapi bisa di-"translate" ke industri lain:

Istilah Scrum	Marketing	Event	Construction
User Story	Campaign Brief	Event Element	Work Package
Sprint	Campaign Cycle	Planning Phase	Build Phase
Story Point	Effort Unit	Task Complexity	Labor Hours
Daily Standup	Team Sync	Morning Briefing	Site Meeting
Sprint Review	Campaign Review	Client Presentation	Walk-through
Product Owner	Brand Manager	Event Director	Project Owner

💡 Tips:

Gunakan istilah yang familiar di industri kamu. Yang penting konsep-nya sama, bukan istilahnya!

🎯 Case Study: Marketing Campaign dengan Agile

📱 Project: Launching Produk Skincare Baru

Tim: 5 orang (Content Creator, Designer, Copywriter, Ads Specialist, Analyst)

Timeline: 4 minggu

Strategi: 4 sprint @ 1 minggu

Sprint 1: Foundation (Week 1)

✅ Brand guidelines & asset kit
✅ Target audience research
✅ Content calendar (first draft)
🎯 Output: Creative brief ready
📊 Review: Client approve concept, request minor adjustment

Sprint 2: Content Production (Week 2)

✅ Instagram posts (12 posts)
✅ TikTok videos (8 videos)
✅ Landing page copy
🎯 Output: Content batch 1 ready
📊 Review: Soft launch, A/B test 2 post variants

Sprint 3: Paid Ads & Scale (Week 3)

✅ Facebook/Instagram ads (3 sets)
✅ Google Ads setup
✅ Influencer seeding (10 micro-influencers)
🎯 Output: Campaign live, data coming in
📊 Review: Variant A outperform B by 30% → focus on A

Sprint 4: Optimize & Report (Week 4)

✅ Campaign optimization based on data
✅ Content batch 2 (based on feedback)
✅ Performance dashboard & report
🎯 Output: Final report + insights for next campaign
📊 Retrospective: What worked? TikTok perform 2x better than expected!

✅ Hasil:

• Campaign selesai on-time & on-budget
• Bisa pivot strategy di Week 3 based on data (ini agile!)
• Client happy karena involved setiap week (sprint review)
• Reach 500K, engagement rate 8.5%, ROI 4.2x

🏗️ Case Study: Renovasi Rumah dengan Sprint

🏠 Project: Renovasi 2 Kamar + 1 Kitchen

Tim: 5 orang (Foreman, 2 Tukang, Electrician, Plumber)

Timeline: 8 minggu

Strategi: 4 sprint @ 2 minggu

Sprint 1-2: Kamar Utama (4 minggu)

Demolition → Rewiring → Plumbing → Tiling → Painting → Finishing

✅ Done! Owner bisa pakai kamar sementara renovasi lanjut.

Sprint 3: Kitchen (2 minggu)

Cabinet install → Countertop → Backsplash → Sink & faucet

✅ Done! Owner bisa masak lagi.

Sprint 4: Kamar Anak (2 minggu)

Paint → Flooring → Built-in closet → Lighting

✅ Done! Anak bisa pindah ke kamar baru.

💡 Keuntungan Agile untuk Renovasi:

• Incremental value: Kamar utama selesai dulu → langsung bisa dipakai
• Budget flexibility: Sprint 3 bisa adjust scope jika budget ketat
• Risk mitigation: Ketemu masalah di Sprint 1 (pipa bocor) → fix sebelum lanjut
• Change friendly: Owner mau ubah warna di Sprint 3? No problem, belum mulai!

🎯 Tips Praktis per Industri

📱 Marketing & Creative

✓ Sprint lebih pendek (1 minggu) → trend cepat berubah
✓ Daily standup cukup 5 menit → team creative perlu fokus time
✓ Sprint review = client presentation dengan data
✓ Gunakan metrics real-time (engagement, reach, CTR)

🎪 Event Management

✓ Sprint focus per domain (artist, venue, marketing, logistik)
✓ Hard deadline → work backward dari event date
✓ Daily standup critical → banyak moving parts
✓ Buffer sprint untuk contingency (cuaca, vendor issue)

🧴 Physical Product

✓ Sprint harus consider lead time (manufacturing 4-6 minggu)
✓ Prototype & testing di early sprint → avoid costly rework
✓ Regulatory approval parallel track (BPOM bisa 3 bulan)
✓ Sprint review = physical sample + test result

🏗️ Construction & Renovation

✓ Sprint per area/room → incremental delivery
✓ Weather-dependent → buffer dalam planning
✓ Material procurement early → avoid blocker
✓ Daily standup di site → solve issue on-the-spot

🎬 Content Production

✓ Sprint = batch episodes (4-6 episodes per sprint)
✓ Production & post-production parallel track
✓ Feedback dari audience → iterate content strategy
✓ Sprint review = pilot screening + analytics

📚 Education & Training

✓ Sprint per module → release incrementally
✓ Pilot with small cohort → improve before scale
✓ Student feedback real-time → adjust content
✓ Interactive > perfect → iterate based on learning data

⚖️ Kapan Agile Cocok vs Tidak Cocok?

✅ Agile COCOK untuk:

• Project dengan requirement yang bisa berubah
• Butuh feedback cepat dari client/user/audience
• Project kompleks & uncertain → belajar sambil jalan
• Tim yang self-organizing & collaborative
• Stakeholder yang involved & available untuk review berkala

Contoh: Startup app, marketing campaign, content series, MVP product

❌ Agile KURANG COCOK untuk:

• Project dengan requirement 100% fixed dari awal
• Regulasi ketat yang tidak bisa iteratif (pharmaceutical trials)
• Project yang sequential & dependency tinggi (rocket launch)
• Tim/client yang tidak bisa commit untuk frequent review
• Infrastructure yang ga support deployment cepat

Contoh: Bridge construction (fixed blueprint), mass manufacturing (fixed design)

🔀 HYBRID bisa untuk:

• Core fixed, features flexible (e.g., construction dengan custom interior)
• Phase 1 agile (MVP), Phase 2 waterfall (scale production)
• Some teams agile, some teams waterfall (creative vs ops)

Kuncinya: Adapt framework ke context, jangan kaku!

🌟 Kesimpulan: Agile is a Mindset!

✨ Agile bukan tentang ritual (daily standup, sprint, dll), tapi tentang value:

• Deliver value secara incremental
• Collaborate dengan customer/stakeholder
• Respond to change lebih baik dari follow plan buta
• People & interaction lebih penting dari process rigid

💡 Jangan terjebak istilah! Adapt Agile ke industry & context kamu.

Mau jadi PM software? Marketing? Event organizer? Construction manager? Prinsipnya sama!

🎉 Siap Praktek?

Coba simulasi PM dari berbagai industri di tab Simulasi PM!

🧮 Kalkulator Sprint

Hitung kapasitas tim (jam kerja tersedia), velocity (kecepatan kerja), dan estimasi berapa sprint yang dibutuhkan.

📐 Rumus & Cara Kerja

1️⃣ Base Capacity (Kapasitas Dasar)

Jumlah Member × Jam/Hari × Hari Sprint

Contoh: 5 orang × 8 jam/hari × 10 hari = 400 jam
Artinya: Total jam kerja yang dimiliki tim jika tidak ada gangguan apapun.

2️⃣ Adjusted Capacity (Kapasitas Setelah Dikurangi)

(Base - Total Hours) × Percent1 × Percent2 × ...

Langkah:
1. Kurangi base dengan parameter Hours (meeting, support, dll)
2. Kalikan dengan parameter Percent (focus, efisiensi, dll)

Contoh: (400 jam - 50 jam meeting) × 80% focus = 280 jam
Artinya: Jam kerja efektif yang benar-benar bisa digunakan untuk coding/kerja.

3️⃣ Velocity (Kecepatan Tim)

Total SP Selesai ÷ Jumlah Sprint

Contoh: Sprint 1 = 20 SP, Sprint 2 = 18 SP, Sprint 3 = 22 SP
Velocity = (20+18+22) ÷ 3 = 20 SP per sprint
Artinya: Rata-rata tim bisa menyelesaikan 20 Story Point setiap sprint.

4️⃣ Estimasi Sprint Dibutuhkan

Total Backlog SP ÷ Velocity Rata-rata

Contoh: Backlog = 200 SP, Velocity = 20 SP/sprint
Estimasi = 200 ÷ 20 = 10 sprint
Artinya: Butuh sekitar 10 sprint untuk menyelesaikan semua pekerjaan.

💡 TIPS:

• Parameter Hours mengurangi jam (meeting, cuti, support)
• Parameter Percent mengalikan (focus 80% = dikali 0.8)
• Velocity makin stabil setelah 3-5 sprint
• Jangan over-commit! Gunakan velocity rata-rata yang realistis

📋 Data Dasar Tim

Jumlah Anggota Tim

Berapa orang dalam tim yang akan bekerja di sprint ini?

Jam Kerja per Hari

Berapa jam kerja efektif per hari? (Biasanya 7-8 jam)

Durasi Sprint (Hari)

Berapa hari sprint berlangsung? (Biasanya 10-14 hari kerja)

Total Pekerjaan (SP)

Berapa total Story Point dari semua pekerjaan yang ada di backlog?

Velocity History

Velocity rata-rata

0 SP

Parameter Kapasitas

Nama	Tipe	Nilai	Note	Aksi

Hasil

Capacity (Jam)

0 jam

Estimasi Sprint (desimal)

Estimasi Sprint (rounded)

📝 Backlog Planner (Multi Sprint)

Rencanakan story untuk setiap sprint dan pantau apakah sesuai velocity.

📐 Cara Kerja Planner

🎯 Prinsip Sprint Planning:

Total SP Story di Sprint ≤ Velocity Target

Aturan Emas: Jangan over-commit! Total SP story dalam sprint sebaiknya tidak melebihi velocity target.
Contoh: Velocity target = 20 SP, Story yang dipilih total = 18 SP ✅ (Aman)

📊 Parameter yang Perlu Diisi:

• Nama Sprint: Identitas sprint (Sprint 1, Sprint Jan 2024, dll)
• Velocity Target: Berapa SP yang realistis diselesaikan? (Pakai hasil dari Calculator)
• Judul Story: Nama task/fitur yang akan dikerjakan
• SP: Story Point untuk masing-masing story
• Assignee: Siapa yang bertanggung jawab
• Status: Todo / In Progress / Done

⚖️ Indikator Status:

✅ Aman: Total SP ≤ Velocity Target (Bagus! Tim tidak overload)
⚠️ Over: Total SP > Velocity Target (Risiko! Kurangi scope atau pecah story)

💡 BEST PRACTICE:

• Prioritaskan story yang memberikan nilai bisnis tertinggi
• Pecah story besar (>8 SP) jadi lebih kecil
• Sisakan 10-20% buffer untuk bug/hal tak terduga
• Sprint Goal harus jelas dan terukur

Konfigurasi Sprint

Pilih Sprint

Nama Sprint

Velocity Target (SP)

Total SP dalam Sprint

Daftar Story

Judul	SP	Assignee	Status	Aksi

Tips: jika Total SP > Velocity Target, kurangi scope atau pecah story.

👥 Capacity per Member

Hitung kapasitas tim berdasarkan kondisi individual setiap anggota.

📐 Rumus Capacity per Member

🧮 Rumus:

((Hari Sprint - Cuti) × Jam/Hari - Support Jam) × Focus %

Urutan Perhitungan:
1. Kurangi hari sprint dengan hari cuti
2. Kalikan dengan jam kerja per hari
3. Kurangi dengan jam untuk support/incident
4. Kalikan dengan persentase focus

📊 Penjelasan Parameter:

• Hari Sprint: Durasi sprint dalam hari kerja (contoh: 10 hari)
• Jam/Hari: Jam kerja efektif per hari (biasanya 7-8 jam)
• Cuti (hari): Berapa hari member tidak masuk selama sprint
• Support (jam): Total jam untuk handle support/incident/production issue
• Focus (%): Persentase waktu untuk fokus kerja sprint (70-90% normal)

💡 Contoh Perhitungan:

Member: Andi
• Hari Sprint: 10 hari
• Jam/Hari: 8 jam
• Cuti: 2 hari
• Support: 6 jam
• Focus: 80%

Perhitungan:
((10 - 2) × 8 - 6) × 0.8
= (8 × 8 - 6) × 0.8
= (64 - 6) × 0.8
= 58 × 0.8
= 46.4 jam

💡 TIPS:

• Focus 70-80% adalah normal (meeting, email, break)
• Junior developer: focus 60-70% (masih belajar)
• Senior dengan banyak meeting: focus 50-60%
• Total Capacity Tim = Jumlah capacity semua member

Setting Sprint

Hari Sprint

Jam kerja / hari

Total Capacity Tim

0 jam

Daftar Member

Nama	Cuti (hari)	Support (jam)	Focus (%)	Capacity (jam)	Aksi

Rumus per member: ((hariSprint - cutiHari) × jam/hari - supportJam) × focus%

📊 Dashboard Overview

⚡ Quick Actions

📜 Recent Activity

Selamat Datang di Sprint Tools!

🚀 Mulai Cepat (5 Langkah Mudah)

📌 Rumus

🎯 Story Point (SP)

⚙️ Parameter Kapasitas yang Umum

💾 Auto Save

🎓 Belajar Agile & Scrum

🔍 Bayangkan Skenario Ini...

🏗️ Scrum adalah Framework

Product Owner (PO)

Scrum Master

Development Team

1. Sprint Planning

2. Daily Standup (Daily Scrum)

3. Sprint Review

4. Sprint Retrospective

📱 Proyek: Aplikasi Toko Online "BelanjaKuy"

✅ DO (Lakukan Ini)

❌ DON'T (Jangan Lakukan)

🚀 Untuk Tim Baru

📏 Estimasi Story Point

🎯 Sprint Goal yang Baik

🛠️ Tools yang Membantu

🎯 Pertanyaan Penting

🧮 Formula Dasar

🗓️ Pendekatan 2: Time-Boxed (Ada Deadline)

🚀 Pendekatan 3: MVP-First (Incremental Release)

⚙️ Faktor Penyesuaian

📊 Contoh Real: Project E-Commerce

💡 Mitos yang Salah

🔄 Prinsip Universal Agile

📋 Adaptasi Terminologi per Industri

🎯 Case Study: Marketing Campaign dengan Agile

🏗️ Case Study: Renovasi Rumah dengan Sprint

🎯 Tips Praktis per Industri

⚖️ Kapan Agile Cocok vs Tidak Cocok?

🎉 Siap Praktek?

📖 Kamus Istilah untuk Pemula

Agile

Sprint

Story Point (SP)

Velocity

Backlog

Capacity

User Story

DoD (Definition of Done)

Scrum Master

Product Owner (PO)

Sprint Planning

Daily Standup

Retrospective

Burndown Chart

Acceptance Criteria (AC)

💡 Tips untuk Pemula:

🎮 Simulasi PM Interaktif

💻 IT & Technology

Startup App

E-Commerce

Internal Tool

🎨 Creative & Marketing

Marketing

Content

Event

🏗️ Physical & Operations

Product

Renovation

Education

📋 Apa yang akan kamu lakukan?

Progress

🎯

🧮 Kalkulator Sprint

📐 Rumus & Cara Kerja

📋 Data Dasar Tim

Velocity History

Parameter Kapasitas

Hasil

📊 Rubrik Story Point (SP)