Select the next useful work
We identify the highest-priority tasks needed for the next useful version. The selected work does not need to contain every feature or improvement you may want later.
Plan the important work. Pay for what is completed.
Together, we select and estimate the highest-priority work for the next useful version. You pay for the work that is completed and accepted.
How the current estimate is prepared
Define the selected tasks
We define the selected work at the granularity needed for a reliable estimate, divide it where necessary, and record important assumptions, exclusions, dependencies, and completion conditions.
Keep later ideas visible
Lower-priority ideas remain in the wider plan. They do not increase the current price estimate until they are selected and sufficiently defined.
How selected tasks are estimated
When a task is selected and sufficiently defined, we assign it a story-point value. A story point is a pricing and planning unit that represents the task's overall size—including implementation, decisions, uncertainty, and verification—not only the visible feature.
Each completed and accepted story point is currently $35.
A selected task's story-point value normally remains unchanged once its intended outcome and major requirements are agreed. Work considered for later may have only a rough planning size until it is selected and sufficiently defined.
Example
Task sizes in an established reminder application
These examples show the relative size of well-defined work in an established reminder application. The same visible feature may receive a different value when its foundations, requirements, dependencies, or verification needs differ.
| Example task | Context | Story points |
|---|---|---|
| Add another preset snooze duration | Arbitrary snooze times already work | 2 |
| Bugfix: Show the empty state immediately after the last reminder is deleted | — | 3 |
| Add and verify a health check for an already containerized reminder application | — | 3 |
| Add All, Active, and Completed filters to the existing reminder list and API | — | 5 |
| Add a CSV export option for the currently filtered reminder list | — | 5 |
| Add email registration, sign-in, password reset, and protected access | The external authentication service is already selected and configured | 8 |
| Create a protected web portal where users can view reminders and account information | Authentication is already working with the mobile app | 13 |
The examples are illustrations rather than a menu of fixed feature prices. Before implementation, the actual task is defined and estimated in the context of the application where it will be completed.
How to read the task sizes
2 story points usually represents a small, localized change in a familiar part of the application, with few decisions and direct verification.
3 story points usually represents a bounded change to one small flow or existing behavior, with a known implementation approach and focused testing.
5 story points usually represents a complete small task that touches several connected parts but has limited uncertainty.
8 story points usually represents a multi-part task with meaningful implementation, integration, security, or verification work.
13 story points usually represents broad but bounded work involving several connected behaviors, important decisions, or integration risks.
Why these values? We use the values 1, 2, 3, 5, 8, and 13. They follow the Fibonacci sequence, whose increasing gaps make practical comparisons easier when work contains some uncertainty. Across a plan containing several smaller tasks, differences between individual estimates also tend to balance.
How time is used for calibration. Internally, one story point represents roughly 25 minutes of experienced developer work and, where useful, about 15 minutes of AI runtime. Standard task billing uses the task's agreed story-point value rather than measured minutes. The time calibration is used directly only when a specific agreement requires human time or AI use itself to be converted into billable story points. AI runtime used during development is included and is not billed separately.
How the first useful version is planned
A product idea often contains more work than is needed for its first useful version. Together, we set priorities and select the tasks that fit the intended result and budget. The remaining work stays visible below the first-version boundary for later.
We add the story points for the selected tasks and compare that total with the number planned for each two-week period. This provides approximate timing for the first version.
- Must have
- Required for the first useful version.
- Should have
- Important, but can be included now or later.
- Good to have
- Useful work for a later version.
- Defer
- Intentionally left out for now.
Example
Planning an appointment-booking application
| Priority | Work | Story points |
|---|---|---|
| Must have | Set the business's appointment types, available hours, and appointment length | 8 |
| Must have | Show available appointment times | 8 |
| Must have | Let a customer choose a time and enter contact information | 5 |
| Must have | Prevent the same time from being booked twice | 8 |
| Must have | Show the business its upcoming bookings | 5 |
| Should have | Let the business cancel or reschedule a booking | 8 |
| Planned first version ends here42 STORY POINTS • 30 STORY POINTS / TWO WEEKS • ABOUT THREE WEEKS | ||
| Should have | Send automatic appointment reminders | 8 |
| Good to have | Synchronize bookings with an external calendar | 13 |
| Good to have | Let customers add notes before the appointment | 3 |
| Defer | Accept online payment | — |
| Defer | Support several business locations | — |
| Defer | Create a separate mobile application | — |
Simplified illustration: a real project uses its own starting point, tasks, priorities, and estimates.
Discuss your project and a delivery option
Tell us what you want to build or improve, what already exists, and which result matters first. The initial conversation is free.
Send an email