You will be creating an online web application bookstore which targets a particular niche in technology. The application, named Geek Text (think of Thinkgeek meets Barnes and noble) will need to support the following features:

FeatureID	Feature	Benefit
1	BookBrowsingand Sorting	Users will have a simple and enjoyable way to discover new books and Authors and sort results. DESCRIPTION: Allow user to browse books by genre, top sellers in our book store, and book ratingwith pagination based on 10 or 20 results. Allow Sort by book title, author, price, book rating, andrelease date.
2	ProfileManagement	Users can create and maintain their profiles rather than enter in their information each time they order DESCRIPTION: Users can manage their login credentials (ID, password), personal information(name, email address, home address), nickname for book rating and commenting, credit cardinformation (multiple), and shipping address (multiple). Physical addresses, email addresses, andcredit card info should be verified as valid. Passwords must meet our current security standards
3	ShoppingCart	Users can manage items in a shopping cart for immediate or future Purchase DESCRIPTION: Users can easily access their cart from any page, view the same informationdisplayed in the book list, change the quantity, remove it from their cart or save it for later. A subtotalfor all items in their shopping cart should be displayed at the bottom. Items saved for later shouldappear below that.
4	Book Details	Users can see informative and enticing details about a book DESCRIPTION: Display book name, book cover (which can be enlarged when clicked), author andbio, book description, genre, publishing info (publisher, release date, etc.), book rating, andcomments. Hyperlink authors name to a list of other books by the same author.
5	Book RatingandCommenting	Users can rate AND comment on books theyve purchased to help others in their selection DESCRIPTION: For Rating: Use a five-star rating system. Users can only rate a book if theyvepurchased it, and may select whether they show their nickname (defined in their profile) or remainanonymous. For Commenting: A single comment should be limited to the number of characters,which can fit within half the browser window (so that there are at least two comments which canappear at the same time). Users can only comment on a book if theyve purchased it, and may select whether they show their nickname (defined in their profile) or remain anonymous.

6

Wish List Management

Users can create and have 3 different wish lists which can have books moved to from the primary list.

DESCRIPTION: There will be a section called wish lists, in which the user can create up to 3 new lists and give them different names. Each list can show the items that have been added to the list and each item can be added to the cart. Items can be added to the different lists from the item details page. Items can be removed from any list in this section. Items can be transferred from one wish list to another.

The grading will be split into team components and group components. Each feature will be owned by a team member. Each member will be graded for the completion and implementation of the feature that they own. This means that although you will earn an overall team grade from the team components, each person in the team will be responsible for a feature being done. If the feature is no completed, the individual who owns the feature will not receive the implementation portion of the grade.

How will the group develop the web application?

The team will use scrum, which is an agile methodology used to develop software. You will need to review Lecture 1 Scrum to become familiar, but here is a summary:

The team will develop the application in timeboxed intervals known as Sprints. Each Sprint has a start date and an end date. At the beginning of the sprint, the team conducts a sprint planning meeting, in which they discuss and estimate what is the functionality that they will implement during that Sprint. The functionality will be implemented by breaking down the features into user stories. A user story is a description what the software must do, the benefit and the acceptance criteria. During the sprint, the team will meet through a meeting known as the standup or daily scrum, in which each team member mentions what they are working on, what they have accomplished and any impediments. It is expected that the team does at least 2 standup meetings each week. Finally, after the sprint has finished, the team hosts a Sprint Review, a meeting in which they demo (show) the work that was completed during the sprint. After the Review, the team performs a Sprint Retrospective (Retro) in which they discuss what has gone well and what can be improved. Its a chance for the team to incorporate improvements for the next Sprint. After completing the Sprint Retrospective, they will then schedule the sprint planning meeting for the next sprint and the process starts again.

Roles:

The teams will consist of 6 people which will be the following during each sprint:

4 Developers: The developers will be responsible for creating their feature and writing their own users stories.

1 Product Owner: This will be an alternating role each sprint. This person will review the backlog of all the user stories written by developers and make sure they meet the requirements of the features. They will be responsible for asking any questions for that sprint regarding product functionality to the instructor. This will be a shared role as it is expected that they also pull in some stories for development

1 Scrum Master: Another alternating role each sprint. The scrum master will be the lead person who oversees removing any impediments and bringing up any issues to the instructor during the sprint. This will be a shared role as it is expected that they also pull in some stories for development.

The team will have a different Product Owner and Scrum Master in each sprint, so everyone will have an opportunity to work under each role.

Velocity:

Velocity is the measurement of how much work will be done. We will use hour units to estimate our work. So, if a person is working on a given user story that will take them 6 hours to achieve, this will be the estimated effort of their user story:

A User Story is a description of the development task that has to be done, so the teams will have multiple user stories and hour estimate to each user story.

Each team will calculate their capacity (how much work they can do) for the sprint in the following manner:

Each developer is expected to work 4 hours a week, so each developer will have an 8-hour allocation per Sprint.

So, 6 developers * 8 = 48 combined hours of work for each a team per Sprint.

The product owner during the sprint will be in charging of grooming the backlog and breaking down the features into user stories.