Writing Stories with Tobi

How to use Tobi to turn rough ideas into clear, actionable Stories.

Tobi helps you turn rough product ideas into structured Stories that are easier for your team to understand, estimate, and build.

You do not need to write a complete Story before asking for help. Start with what you know, then use Tobi to add structure, fill in missing context, improve Acceptance Criteria, and split Stories when needed.

Starting from a rough idea

Open a Story and click the Tobi icon to start working with Tobi.

You can begin with something as simple as:

“Users need a way to reset their password by email.”

Tobi can turn that rough idea into a structured Feature Story, for example:

Title: Allow users to reset their password by email

Type: Feature

Why

As a registered user I want to reset my password via email So that I can regain access to my account if I forget my password

Acceptance Criteria

Scenario: User successfully resets password via email Given I am on the login page When I click “Forgot Password” and enter my registered email address Then I should receive a password reset email with a secure link And when I click the link, I should be able to set a new password And after setting the new password, I should be able to log in with it

Tobi can suggest:

  • A clear Story title
  • The appropriate Story type
  • A persona or user
  • What the user wants to do
  • Why it matters
  • Testable Acceptance Criteria

Some of these details may be assumptions based on the context you provide. Review Tobi’s suggestions before applying them, especially any product behavior that was not included in your original draft.

Writing Bug Stories

Tobi can also turn rough Bug notes into a structured Bug Story.

You can start with an incomplete description such as:

“Password reset link sometimes opens an error page.”

Tobi can organize the information into a clearer Bug format, including:

  • Steps to reproduce
  • Expected behavior
  • Actual behavior
  • Relevant context or conditions

You do not need to format the Bug first. Give Tobi the information you have, and use the result as a draft for the team to review.

Reviewing an existing Story

When you first ask Tobi about an existing Story, include the Story ID so Tobi knows exactly which Story you mean.

For example:

“Review #200019204 for missing information.”

or

“Are the Acceptance Criteria in #200019204 clear and testable?”

Tobi does not automatically assume that the Story currently open in the modal is the Story you are referring to.

Once a Story has been identified in the conversation, you can use shorter references such as:

“Can you improve this Story?” “Does this Story need a clearer persona?” “Can you split this Story?”

Tobi will use the Story already established in the conversation context.

Useful requests include:

  • “Review #200019204 for missing information.”
  • “Is the persona in #200019204 clear?”
  • “Does #200019204 explain why the user needs this?”
  • “Are the Acceptance Criteria in #200019204 clear and testable?”
  • “Should #200019204 be split?”
  • After that: “Can you improve this Story?”

If a Feature Story is missing a persona, Tobi can suggest one based on the Story context.

If the Story explains what should happen but does not clearly explain why it matters, Tobi can use the existing context and Acceptance Criteria to suggest the user or business value behind the Story.

Improving Acceptance Criteria

Clear Acceptance Criteria make it easier for the team to understand what needs to be true for a Story to be accepted.

When starting a new conversation about a Story, include its Story ID:

“Review and improve the Acceptance Criteria for #200019204.”

After Tobi has identified the Story, you can continue with:

“Can you make them more specific and testable?”

Tobi can identify vague or incomplete criteria and rewrite them as more specific, verifiable conditions.

When appropriate, Tobi can structure Acceptance Criteria using scenarios such as Given / When / Then.

Always review the suggested criteria to make sure they reflect the product behavior you actually want.

Splitting large Stories

If a Story contains too much scope or combines multiple pieces of user value, Tobi can help break it into smaller Stories.

Start by identifying the Story:

“#200019204 seems too large. Can you split it into smaller Stories?”

Once the Story is established in the conversation, you can follow up with:

“Can you make the split even smaller?”

Tobi can propose smaller Stories and explain how the original scope could be separated while preserving its intent.

Owners and Members can review the proposed split and create the new Stories directly in Tracker Boot.

Tips

  • Use the Story ID first. When starting a conversation about an existing Story, reference it with its ID, such as #200019204.
  • Use “this Story” after the context is established. Once Tobi knows which Story you are discussing, shorter references work naturally.
  • Do not assume the open modal is automatically in context. Opening a Story on screen does not by itself tell Tobi that it is the target of your question.
  • Start rough. You do not need to write a perfectly formatted Story before using Tobi.
  • Give Tobi the context you already have. Even incomplete notes, existing Acceptance Criteria, or Bug details can help.
  • Use Tobi to find what is missing. Persona, user value, unclear scope, and weak Acceptance Criteria are all useful things to review.
  • Iterate. Ask follow-up questions and refine the Story until it is clear enough for the team to understand and estimate.
  • Review assumptions. Tobi may suggest details that were not explicitly included in your original draft.
  • Keep product judgment with the team. Tobi helps structure and improve Stories, but the final Story should reflect the intended user value and product behavior.