Choose Your Approach
Toolwiz adapts to how you think. Whether you prefer plain language, Scrum methodology, or engineering specifications — the platform speaks your language while delivering the same quality.
What is a Development Methodology?
A development methodology is the framework that structures how software gets planned, built, and delivered. It defines the language teams use, the rituals they follow, and the quality gates that protect the final product. Choosing the right methodology is not about picking the "best" one — it is about picking the one that fits how you and your team already think.
Traditional development forced everyone into a single vocabulary. Technical founders had to learn Scrum. Non-technical stakeholders had to decode engineering jargon. The result was miscommunication, frustration, and projects that drifted from their original vision.
Toolwiz solves this with toggleable terminology modes. The underlying process — structured planning, quality gates, iterative delivery — stays the same. Only the language changes. You can switch between modes at any time, per user, without affecting your project data or workflow.
Three Modes
Same powerful process, different vocabulary. Each mode is designed for a specific audience.
Simple
simplePlain language for everyone
Designed for non-technical founders, business stakeholders, and first-time users. No jargon, no acronyms — just clear descriptions of what is happening with your project. Feature requests instead of stories, development cycles instead of sprints, quality checks instead of definitions of done.
Non-technical founders, business stakeholders, first-time users
Scrum
scrumThe agile standard
The industry-standard agile framework created by Ken Schwaber and Jeff Sutherland. Familiar to product managers, Scrum practitioners, and agile teams worldwide. Stories, sprints, backlogs, and retrospectives — every Scrum concept maps directly to Toolwiz features.
Scrum practitioners, agile teams, product managers
Spec
specEngineering precision
Built for CTOs, solo technical founders, and engineers who think in specifications and test cases. Specifications instead of stories, iterations instead of sprints, acceptance tests instead of definitions of done. Every concept maps to engineering-first vocabulary.
CTOs, engineers, solo technical founders
Terminology Comparison
Every concept has three names — one for each mode. The same data, the same quality gates, just different language.
| Concept | Simple | Scrum | Spec |
|---|---|---|---|
| Work unit | Feature request | Story | Specification |
| Time box | Development cycle | Sprint | Iteration |
| Queue | Feature queue | Backlog | Spec backlog |
| Entry gate | Readiness check | Definition of Ready | Spec review |
| Exit gate | Quality check | Definition of Done | Acceptance test |
| Success criteria | Success conditions | Acceptance criteria | Test cases |
| Effort measure | Effort units (EU) | Story points (SP) | Complexity score (CS) |
| Large grouping | Project milestone | Epic | Module |
| Speed metric | Delivery speed | Velocity | Throughput |
| Review | Performance review | Retrospective | Iteration review |
| Board | Project dashboard | Scrum board | Spec tracker |
Scrum Deep Dive
Scrum is the most widely adopted agile framework. Created in the early 1990s, it provides a structured approach to iterative development where work is delivered in short cycles called development cycles. Here is how every Scrum concept maps to Toolwiz.
Scrum Values
Five values form the foundation of Scrum. Without them, the practices become empty rituals.
Commitment
The team commits to achieving development cycle goals and supporting each other.
Every development cycle has a locked scope. AI and engineers commit to delivering approved feature requests within the development cycle.
Focus
Everyone focuses on the development cycle work and the goals of the team.
One development cycle at a time. AI works on approved feature requests only — no scope creep, no distractions.
Openness
The team and stakeholders are open about work and challenges.
Your project dashboard is always up to date. Feature request progress, blockers, and quality metrics are visible in real time.
Respect
Team members respect each other as capable, independent people.
Stakeholders own the "what," engineers own the "how." Each role has clear authority and responsibility.
Courage
Team members have the courage to do the right thing and tackle tough problems.
Quality gates enforce standards even when it's tempting to cut corners. If something isn't ready, it doesn't ship.
Scrum Roles
Three accountabilities ensure clear ownership. In Toolwiz, you fill the most important one.
Product Owner
That's youMaximizes the value of the product by managing the Product Feature Queue. The PO decides what to build, sets priorities, and ensures the team works on the most valuable items first.
You are the Product Owner. You describe features, set priorities, approve development cycle scope, and accept or reject deliveries. An AI Product Owner assists you — creating feature requests from your descriptions, estimating effort, and organizing the feature queue — but you make every decision.
Scrum Master
Serves the team by facilitating Scrum events, removing impediments, and ensuring the process is followed correctly.
The platform acts as your Scrum Master. It enforces readiness check before development cycles start, quality check before feature requests complete, and runs performance reviews automatically.
Developers
The people who do the work of delivering a potentially releasable increment each development cycle.
AI and experienced engineers form the development team. AI handles implementation, engineers ensure quality through code review.
Scrum Events
Five events create regularity and minimize the need for ad-hoc meetings.
Development Cycle
A fixed time-box (typically 1-4 weeks) where a "Done," usable increment is created.
Development cycles follow the standard Scrum cadence. Each development cycle delivers working software that you can review and approve.
Development Cycle Planning
The team selects work from the Product Feature Queue for the upcoming development cycle and creates a plan for delivery.
You chat with the AI to describe what you want built. Feature requests are created with success conditions and effort unit estimates.
Daily Scrum
A 15-minute event for developers to inspect progress toward the development cycle goal.
No daily standup meetings needed. Your board shows real-time progress — feature requests move automatically as work completes.
Development Cycle Review
The team presents completed work to stakeholders at the end of the development cycle.
You review each completed feature request against your success conditions. Accept what meets expectations, request changes on what does not.
Performance Review
The team reflects on the past development cycle to identify improvements for the next one.
Development cycle metrics are tracked automatically — delivery speed, estimation accuracy, quality scores. The AI suggests process improvements.
Scrum Artifacts
Artifacts represent work or value. They maximize transparency so everyone has the same understanding.
Product Feature Queue
An ordered list of everything that might be needed in the product.
Your feature queue lives on the project dashboard. Feature requests are created from conversations, organized by priority, and estimated in effort units.
Development Cycle Feature Queue
The set of Product Feature Queue items selected for the development cycle, plus a plan for delivering them.
The development cycle feature queue is the set of feature requests you approved during development cycle planning. Once the development cycle starts, scope is locked.
Increment
The sum of all completed items during a development cycle. Each increment must be "Done" — usable and potentially releasable.
Every development cycle produces working software delivered to a managed repository. Each delivery meets the quality check — tested, reviewed, and approved.
Effort Units
A unit of estimation that represents relative complexity, not hours. Teams use Fibonacci-like sequences (1, 2, 3, 5, 8, 13…) to size feature requests.
AI estimates effort units by analyzing your project scope — architecture, dependency graph, test coverage needed. Your monthly plan includes an effort unit allocation. See pricing plans →
Spec-Driven Engineering
For engineers and CTOs who think in specifications, test cases, and system design.
Spec-driven development starts with precise specifications rather than feature requests. Each feature is described as a technical specification with explicit inputs, outputs, constraints, and acceptance tests. This approach eliminates ambiguity and gives engineers full control over the technical direction.
In Toolwiz, Spec mode transforms the entire interface vocabulary. Development cycles become iterations. Feature requests become specifications. Success conditions become test cases. The quality check becomes an acceptance test. For teams that already think in specifications, this removes the cognitive overhead of translating between business language and engineering language.
The underlying process remains identical — structured planning, quality gates, AI-accelerated implementation, and mandatory engineer review. Only the language changes, making the platform feel native to engineering-first teams.
Specification First
Every feature starts as a detailed specification with clear inputs, outputs, and constraints — no ambiguity, no interpretation drift.
Test-Case Driven
Acceptance tests are defined before implementation begins. The spec passes when all test cases pass — binary, measurable, unambiguous.
Modular Architecture
Work is organized into modules (not project milestones) with explicit dependency graphs. Each module has a clear interface contract and can be developed independently.
Complexity Scoring
Effort is measured in complexity scores (CS) on the Fibonacci scale. Scoring considers algorithmic complexity, integration surface area, and testing requirements.
The Simplified Approach
For founders and stakeholders who want results without methodology jargon.
Not everyone needs to know what a "sprint retrospective" or a "definition of ready" is. The simplified approach strips away all methodology jargon and replaces it with plain-language descriptions that anyone can understand. Feature requests instead of stories. Development cycles instead of sprints. Quality checks instead of definitions of done.
This mode is designed for non-technical founders, business stakeholders, and first-time users of development platforms. The process is exactly the same — the same quality gates protect your project, the same AI acceleration delivers your features, and the same engineer reviews ensure code quality. You just do not need a Scrum certification to understand what is happening.
Simple mode is the default for all new users. As you become more comfortable with the platform, you can switch to Scrum or Spec mode at any time from your user settings. Your project data stays the same — only the labels change.
No Learning Curve
Plain English descriptions mean you can start using the platform immediately without learning Scrum vocabulary or engineering terminology.
Stakeholder Friendly
Share project progress with board members, investors, or non-technical co-founders without needing to explain what "velocity" or "DoR" means.
Same Quality Guarantees
Readiness checks and quality checks are the same gates as DoR and DoD — just described in language that is immediately understandable.
Switchable Anytime
Start with Simple and switch to Scrum or Spec whenever you are ready. Your data, your project, your workflow — nothing changes except the labels.
6-Phase Workflow
Every project follows the same six phases. Each phase name adapts to your chosen mode.
| Phase | Simple | Scrum | Spec |
|---|---|---|---|
| Onboarding | Project Setup | Onboarding | Initialization |
| Planning | Feature Planning | Sprint Planning | Spec Writing |
| Engineering | Technical Design | Engineering | Architecture Review |
| Implementation | Building | Implementation | Execution |
| Review | Quality Review | Sprint Review | Acceptance Testing |
| Retrospective | Performance Review | Retrospective | Iteration Review |
Which Mode Is Right for You?
Choose based on your role and experience. You can always switch later.
Non-technical founder
You want to focus on your product vision without learning methodology terminology. Simple mode lets you describe features in plain language and track progress without jargon.
Product manager / Scrum practitioner
You already know the framework. Scrum mode uses the vocabulary you are familiar with — stories, sprints, backlogs, velocity — so there is zero translation overhead.
CTO / Technical co-founder
You think in specifications and test cases. Spec mode maps directly to engineering concepts — modules, iterations, complexity scores, acceptance tests.
Agency owner / Team lead
Your team likely uses Scrum already. Scrum mode integrates seamlessly with existing agile workflows and reporting.
First-time platform user
Start with Simple to learn the platform without the overhead of unfamiliar terminology. Switch to Scrum or Spec once you are comfortable.
Solo developer / Indie hacker
You prefer technical precision and direct control over specifications. Spec mode gives you engineering-first vocabulary with no abstraction layers.
See It in Action
Now that you understand the methodology options, see how these concepts come together in the Toolwiz platform — step by step, from project setup to shipped code.
How It WorksSources
- 1 The Scrum Guide — Ken Schwaber & Jeff Sutherland (2020). The definitive guide to Scrum, maintained by its co-creators.
- 2 Scrum.org — Scrum.org . Professional Scrum training and certification body.
- 3 Manifesto for Agile Software Development — Beck, K. et al. (2001). The foundational principles behind agile methodologies including Scrum.
- 4 IEEE Standard for Software Requirements Specifications — IEEE (1998). Industry standard for writing software specifications (IEEE 830).
Common Questions
Can I switch between modes at any time?
Yes. Terminology mode is a per-user setting that you can change anytime from your user settings. Your project data, workflow, and quality gates stay exactly the same — only the interface labels change.
Does the mode affect my project or data?
No. All three modes are different labels for the same underlying data model. A "feature request" in Simple mode is the same entity as a "story" in Scrum mode and a "specification" in Spec mode. Switching modes changes the display language, not the data.
Which mode should I start with?
Simple mode is the default and recommended starting point. It uses plain language that anyone can understand. If you have Scrum experience, switch to Scrum mode. If you prefer engineering terminology, try Spec mode. You can always change later.
Can different team members use different modes?
Yes. Terminology mode is a per-user setting. Your product manager can use Scrum mode while your CEO uses Simple mode — they are both looking at the same project data with different labels.
Do I need Scrum experience to use Toolwiz?
No. Simple mode was designed specifically for users without methodology experience. The platform handles the process for you — structured planning, quality gates, iterative delivery — all described in plain language.
How does pricing work across modes?
Pricing is the same regardless of mode. Simple mode shows "$400 per effort unit," Scrum mode shows "$400 per story point," and Spec mode shows "$400 per complexity score." They all refer to the same unit of work.
Ready to Start Building?
Sign up for free and choose your preferred approach. The platform adapts to you — not the other way around.