Before we go anywhere, we need the highest of high level requirements to drive the first sprint.
At it's most basic a convention registration system must:
- Be a web accessible system (ie, a website).
- Allow a user to choose from a one day or weekend pass.
- Allow a user to sign up for one of the two choices with a name and address.
- Allow an organizer to set the # of available one day passes.
- Allow an organizer to set the # of available daily passes.
- Allow an organizer to remove a user from a convention and free up pass slots.
- Allow the system to refuse a user when passes run out.
- Display using ugly developer art.
All these stories -- they are user stories for basic functionality which, if we were doing it right, would have a customer and acceptance criteria and will get rewritten properly when the time comes -- promptly go into the backlog because they ask other, more pressing, questions:
- Need to write code in a programming language that fits the needs of the project.
- Need to store data in a data store that fits the needs of the data.
- Need to put code on a machine with an operating system.
- Need to store code in an RCS.
- Need to back up the RCS so the code never gets lost or destroyed.
At this point there's no need for caching or scaling. The project has no uptime or user load requirements. It just needs to work at its most basic level and it looks like two sprints just to offer a basic deliverable of a white screen with black text.
We load the first five stories that lay down the foundations of the product -- picking tech and storing it somewhere -- and put the stories driving features into the backlog for sprint #2.
Also, I recommend starting to track user stories in an application called Trello. It's free, it's easy to use, and it will work fine for a very small team (of 1 in this case) tracking a backlog. It's more a Kanban tool than an Agile tool but when one is not spending money, free is the right price.