SprintMind AI is an intelligent Agile coaching system that helps software teams plan sprints, run daily standups, and facilitate retrospectives through natural conversation. Built on Google's Agent Development Kit, it uses four specialized AI agents that collaborate to provide data-driven coaching, real-time sprint analytics, and actionable improvement recommendations.
Live Demo: https://sprintmind-ai-54480702073.us-central1.run.app
Software teams struggle with Agile processes. Scrum Masters are overloaded, sprint planning relies on gut feeling instead of data, standup meetings lose focus, and retrospectives produce action items that nobody follows up on. Most project management tools track tasks but don't actively coach teams on how to improve.
SprintMind AI acts as an always-available Agile coach that understands your sprint data, tracks team health signals, and provides contextual recommendations. Instead of replacing your tools, it sits on top of your sprint data and gives you the coaching layer that's usually missing.
Ask it anything:
- "Plan a new 2-week sprint for our search feature"
- "Log standup for Alice: finished auth module, starting dashboard, no blockers"
- "What's our velocity trend?"
- "Run the sprint retro"
It responds with real data, not generic advice.
User (Natural Language)
|
v
+------------------------------------------+
| sprint_coach (Root Agent) |
| Routes requests to specialists |
| Handles general Agile coaching |
+----+-------------+-------------+---------+
| | |
+----------v--+ +------v------+ +--v-----------+
| sprint_ | | standup_ | | retro_ |
| planner | | agent | | agent |
| | | | | |
| Planning | | Facilitation| | Retrospective|
| Estimation | | Blocker | | Insight |
| Scheduling | | Detection | | Generation |
| Capacity | | Mood Track | | Action Items |
+------+------+ +------+------+ +------+------+
| | |
+-----------v----------------v------------------v---------+
| 12 Function Tools (4 MCP Groups) |
| |
| +------------+ +----------+ +--------+ +-------------+ |
| |Task Manager| |Calendar | |Notes | |Sprint DB | |
| | | | | | | |Analytics | |
| | create_task| |create_ | |log_ | |get_burndown | |
| | update_task| | sprint | |standup | |get_velocity | |
| | get_tasks | |get_sprint| |get_ | |get_team_ | |
| | | | _status | |standup | | capacity | |
| | | |schedule_ | | _hist | | | |
| | | |ceremony | |add_ | | | |
| | | | | |retro | | | |
| +------------+ +----------+ +--------+ +-------------+ |
+--------------------------+------------------------------+
|
+--------------v--------------+
| SQLite Database (WAL) |
| |
| sprints | tasks |
| standups | retrospectives |
| team_members |
+-----------------------------+
The root agent (sprint_coach) receives every user message and makes a routing decision:
- If the request is about planning, task management, or scheduling, it delegates to
sprint_planner - If the request is about daily updates, blockers, or team mood, it delegates to
standup_agent - If the request is about retrospectives, lessons learned, or improvement tracking, it delegates to
retro_agent - If the request is a quick status check or general Agile question, it handles it directly using its own tools
Each sub-agent has access to only the tools it needs, which keeps the Gemini function-calling focused and reduces hallucination. The agents share state through the SQLite database, so the standup agent can see tasks created by the planner, and the retro agent can analyze standup patterns from the entire sprint.
This is the most complex workflow in the system. When a user says "Plan a new sprint", here is what happens step by step:
User: "Plan a 2-week sprint for the search feature"
|
v
sprint_coach receives the message
|
v (Detects planning intent, delegates)
sprint_planner takes over
|
+---> get_velocity()
| Returns: avg 31 pts/sprint, stable trend
| Recommendation: 27.9 pts capacity (10% buffer)
|
+---> get_team_capacity()
| Returns: 5 members, 192 total hours
| Per-member skills and current workload
|
+---> create_sprint()
| Creates: "Sprint 2 - Search Feature"
| Dates: 2 weeks from today
| Capacity: 27.9 pts (data-driven)
|
+---> create_task() x N
| Breaks down user stories into tasks
| Assigns based on skills and capacity
| Estimates using Fibonacci points
|
+---> schedule_ceremony() x 4
| Planning meeting (day 1, 2hr)
| Daily standups (weekdays, 15min)
| Sprint review (last day, 1hr)
| Retrospective (last day, 1.5hr)
|
v
Returns kickoff summary with capacity analysis
User: "Log standup for Alice: finished auth, starting dashboard, blocked on API docs"
|
v
standup_agent takes over
|
+---> get_sprint_status()
| Context: Sprint 1, day 4 of 14
|
+---> log_standup()
| Records: yesterday, today, blockers, mood
| Triggers: BLOCKER ALERT (API docs)
|
+---> update_task()
| Moves "Implement JWT auth" to done
| Moves "Build dashboard" to in_progress
|
+---> get_burndown()
| Returns: 21.6% complete, 11 days remaining
|
v
Returns summary with blocker alert + mood report
User: "Run the sprint retro"
|
v
retro_agent takes over
|
+---> get_sprint_status() --> Final sprint metrics
+---> get_burndown() --> Completion analysis
+---> get_standup_history() --> 2 weeks of mood + blocker patterns
+---> get_tasks() --> What got done vs what didn't
+---> get_velocity() --> Trend comparison with past sprints
|
v
Auto-generates categorized insights:
|
+---> add_retro_note("went_well", "Strong completion at 85%")
+---> add_retro_note("went_well", "Team morale stayed positive")
+---> add_retro_note("to_improve", "High blocker frequency: 5 during sprint")
+---> add_retro_note("action_items", "Add daily blocker-busting slots")
+---> add_retro_note("action_items", "Review estimation accuracy")
|
v
Returns structured retro report with scorecard
| Tool | Purpose | Key Parameters |
|---|---|---|
create_task |
Add a task to the sprint backlog | title, sprint_id, assignee, priority, story_points |
update_task |
Change task status, assignee, or estimate | task_id, status, assignee, priority |
get_tasks |
Query tasks with filters | sprint_id, status, assignee, priority |
| Tool | Purpose | Key Parameters |
|---|---|---|
create_sprint |
Create a new sprint with dates and capacity | name, goal, start_date, duration_days |
get_sprint_status |
Health check with burndown and breakdown | sprint_id (0 for active) |
schedule_ceremony |
Schedule planning, standup, review, or retro | ceremony_type, scheduled_date |
| Tool | Purpose | Key Parameters |
|---|---|---|
log_standup |
Record a team member's daily update | member_name, yesterday, today, blockers, mood |
get_standup_history |
Retrieve standup trends and participation | sprint_id, member_name, days |
add_retro_note |
Add categorized retrospective feedback | category (went_well/to_improve/action_items) |
| Tool | Purpose | Key Parameters |
|---|---|---|
get_burndown |
Burndown data with risk assessment | sprint_id |
get_velocity |
Historical velocity with trend analysis | last_n_sprints |
get_team_capacity |
Per-member workload and availability | (uses active sprint) |
Five tables with foreign key relationships and check constraints:
sprints -- id, name, goal, start_date, end_date, status, velocity, capacity
tasks -- id, sprint_id (FK), title, assignee, status, priority, story_points
standups -- id, sprint_id (FK), member_name, standup_date, yesterday, today, blockers, mood
retrospectives -- id, sprint_id (FK, UNIQUE), went_well, to_improve, action_items, team_rating
team_members -- id, name, role, email, capacity_hours, skills, activeStatus constraints enforce valid state transitions. Mood tracking uses a 5-point scale (great, good, neutral, struggling, blocked). Story points follow Fibonacci sequence convention. The database uses WAL mode for concurrent read performance.
sprintmind-ai/
├── sprintmind/ # ADK agent package
│ ├── __init__.py # Package init (from . import agent)
│ ├── agent.py # ADK entry point, exports root_agent
│ ├── agents/
│ │ ├── sprint_coach.py # Root orchestrator with 3 sub-agents
│ │ ├── sprint_planner.py # Planning, estimation, scheduling
│ │ ├── standup_agent.py # Daily updates, blocker detection
│ │ └── retro_agent.py # Retrospectives, insight generation
│ ├── tools/
│ │ ├── task_manager.py # create_task, update_task, get_tasks
│ │ ├── calendar_tools.py # create_sprint, get_sprint_status, schedule_ceremony
│ │ ├── notes_tools.py # log_standup, get_standup_history, add_retro_note
│ │ └── sprint_db_tools.py # get_burndown, get_velocity, get_team_capacity
│ ├── db/
│ │ └── database.py # SQLite schema, migrations, query helpers
│ ├── workflows/
│ │ └── orchestrator.py # Multi-step workflow definitions
│ └── mcp_servers/
│ └── servers.py # MCP tool registry (4 servers, 12 tools)
├── tests/
│ └── test_sprintmind.py # 30 tests across all layers
├── main.py # Production FastAPI server
├── Dockerfile # Cloud Run container
├── requirements.txt
├── .github/workflows/test.yml # CI pipeline
└── README.md
| Layer | Technology | Why This Choice |
|---|---|---|
| Agent Framework | Google ADK 1.28 | Native multi-agent orchestration with automatic tool routing |
| LLM | Gemini 2.5 Flash | Fast inference, strong function calling, cost effective |
| Database | SQLite (WAL mode) | Zero config, embedded, perfect for per-instance state |
| Server | FastAPI + Uvicorn | Async support, auto-generated OpenAPI docs |
| Deployment | Google Cloud Run | Serverless, scales to zero, pay per request |
| Secrets | Google Secret Manager | Secure API key storage with IAM-based access |
| CI | GitHub Actions | Automated testing on every push |
- Python 3.12 or higher
- A Google Cloud account
- A Gemini API key from AI Studio
git clone https://github.com/Hotragn/sprintmind-ai.git
cd sprintmind-ai
pip install -r requirements.txt
export GOOGLE_API_KEY=your-key-here
export GOOGLE_GENAI_USE_VERTEXAI=FALSE
export SPRINTMIND_DB_PATH=/tmp/sprintmind.db
# Terminal mode
adk run sprintmind
# Web UI mode
python main.py
# Open http://localhost:8080SPRINTMIND_DB_PATH=/tmp/test.db pytest tests/ -vgcloud run deploy sprintmind-ai \
--source . \
--region us-central1 \
--port 8080 \
--memory 512Mi \
--set-env-vars GOOGLE_GENAI_USE_VERTEXAI=FALSE \
--set-secrets GOOGLE_API_KEY=your-secret-name:latest \
--allow-unauthenticatedSprint Planning:
You: Plan a new 2-week sprint for the notification system
AI: I'll check your team's velocity and capacity first...
Your avg velocity is 31 pts/sprint. With a 10% buffer, I recommend
27.9 pts capacity. Let me create the sprint and break down tasks...
[Creates sprint, 6 tasks, schedules all ceremonies]
Sprint 2 is ready! 26 pts planned at 93% capacity utilization.
Daily Standup:
You: Log standup for Dan: yesterday wrote auth tests, today performance
testing, blocked on staging environment access
AI: Logged Dan's update. BLOCKER DETECTED: staging environment access.
Sprint is at 21.6% completion with 11 days remaining.
Recommend: escalate staging access to DevOps immediately.
Retrospective:
You: Run the sprint retro
AI: Analyzing Sprint 1 data...
Scorecard: 31/37 pts delivered (83.8%)
Wins: Strong completion rate, positive team morale (4.1/5)
Improve: 3 blockers during sprint, estimation gap on auth tasks
Action Items:
1. Add daily blocker-busting slots (Owner: Eve)
2. Run estimation workshop before Sprint 2 (Owner: Alice)
Model Deprecation on New Projects:
Google deprecated gemini-2.0-flash for newly created GCP projects while it still works on older ones. We discovered this at runtime and had to dynamically query available models to find gemini-2.5-flash as the working alternative. This taught us to never hardcode model versions.
ADK Web UI Subdirectory Scanning:
The adk web CLI command scans subdirectories for agent packages, which caused our tools/, agents/, and db/ folders to appear as separate agents in the dropdown. We solved this by building a custom main.py using get_fast_api_app() instead of relying on the CLI, giving us control over CORS, session creation, and host binding.
Cloud Run Host Binding:
ADK defaults to 127.0.0.1 which only accepts local connections. Cloud Run requires 0.0.0.0 to accept external traffic. The container built and deployed successfully but failed health checks until we fixed the binding.
Session Creation in Production:
The ADK web server defaults auto_create_session to False, which causes 403 errors when the frontend tries to start a conversation. Setting auto_create_session=True and allow_origins=["*"] in the FastAPI app resolved this.
Data-Driven Coaching, Not Generic Advice: Every recommendation comes from actual sprint data. When the coach suggests reducing capacity, it's because your velocity history shows overcommitment. When it flags a team member, it's because standup mood scores have been declining.
Multi-Agent Specialization: Instead of one monolithic prompt trying to do everything, each agent has a focused instruction set and scoped tool access. The planner doesn't see standup tools, the standup agent doesn't see planning tools. This keeps the LLM's function calling precise and reduces errors.
Full Sprint Lifecycle Coverage: Most Agile tools handle one phase. SprintMind covers planning through retrospective in a single conversational interface, with data flowing between phases. The retro agent can reference standup patterns, and the planner can use velocity from completed sprints.
Production-Ready Architecture: Custom FastAPI server, Secret Manager for credentials, scale-to-zero deployment, 30 automated tests, and CI pipeline. This isn't a demo; it's a deployable system.
- Integration with Jira, Linear, and Asana via MCP tool extensions
- Slack and Teams bot for standup collection
- Persistent Cloud SQL backend for multi-instance state
- Sprint-over-sprint trend dashboards
- Custom team configuration through conversation
MIT
Built with Google ADK for the GEN-AI APAC