As first time founders, setting up our product process @tryMito took many, many iterations. Here is the framework we've created to make sure our sprint stories are actionable, transparent, and scoped.

Would love to hear ideas for our next iteration!

1. Specify the interface between the story and the product, but allow for creativity in implementation.

"Add a taskpane that displays the standard error data type" allows for creativity in design + implementation, but lets other stories know how to interact with it. 2/

2. Write stories to be inclusive — they should be broken down into standalone tasks so that its easy for anyone to pick them up.

Instead of "fix the top 5 usability bugs", break them into individual pieces to reduce coordination costs. 3/

3. Attach specific goals to Non-technical stories.

Technical stories (ie: creating the new taskpane) are inherently scoped enough to avoid feature creep, but our non-technical stories (ie: design the onboarding process) leads to company-altering master plans. 4/

4. Implementing architectural changes should only occur in tandem with the use of the new architecture.

Trying to design + build architecture that you don't need right away is a sure fire way to miss the importance nuance, but a great way to practice refactoring :) 5/

5. Define terms used in the story that might not be interpreted the same by everyone.

We got caught in this trap a bunch of times when talking about the lifecycle of the app. "Ideate on lifecyle solutions" is about as vague as it gets. 6/

Then there are the ones that seem obvious, but still took us a few sprints to figure out.

6. Use tags to prioritize the stories.

7. List the stories that are blocking a particular story in the story itself.

8. Keep track of how much time you spend on each story. 7/