Story of a startup and
ideas on building innovative software
Showing posts with label design. Show all posts
Showing posts with label design. Show all posts

Tuesday, November 14, 2006

Master Story

The first model of your project is probably the most difficult. You need to have an intuitive idea of what best represents the problem you are solving. This is what you need to showcase. Funky algorithms and flash interfaces don't mean much if the core function is erroneous. Get something to people to comment on. Get a story to start from.

Typically start with a master story. A master story is a fairly detailed chapter of what you see the solution doing. Include everything needed to give a full picture of the solution - do look at how you intend to solve it (unless there are novel ideas that should be mentioned), but do go into expectations from all parties (admins, users, system etc). Someone should be able to read it and have a very good idea of the overall picture of your concept. Although it may be more technical than anything outlined in a business plan, it should be targetted at an audience with knowledge of the domain and/or technology - at a high level at least.
AggregateIt will allow registered users to save a URL by right-clicking on any browser page and sending to a central database. The central database will store the URL with the users account and at regular intervals poll the site to check for RSS feed updates. Upon finding updates, the updates from all sites in some period will be aggregated and emailed to the user.

Note that we discuss some concept behind the solution, but leave the detail. There are other points around features such as registration, security and so on that could and should be discussed. Someone can read the master story and break it into many sections which can then discuss the detail - this means that all sections should be covered in some manner in the master story.

Next time we will look at creating sections and sub-stories.

Scope

Probably the first technical thing you should do is get an idea of what is in scope for the first release. Scoping is about knowing what you want to deliver in some duration of an iteration. You really wnat to make this as short as 1 - 2 weeks per minor version. The initial period won't be like that as you are still fully understanding what you are trying to create, but after this period (typically the first month) you should get to minor releases and many iterations.

The scoping document outlines the overall intentions of a full major iteration and the current release points. You may have many minor scoping documents within each release, but it keeps everyone (even it it's just yourself!) on track.

The key components are :
1. Overview
2. Major Release
3. Current
Release
4. Schedule
5. Outputs
6. Next
Steps
7. References

You can download a template for a scoping document from here or you can download from the "Templates" link on the right.