Introduction to Software Engineering:

For this assignment, the objective is to gain knowledge and understanding in the practice of using agile methods/techniques to plan the first release of a new software system. Product Owners Vision (Epic Story) Currently, a customer can place an order by phoning a pizza store. When an employee answers, the customer begins telling the employee what it is theyd like to order, such as: Yea, this is Bob and Id like to order a medium thick-crust pizza and on 1/2 Id like a supreme with extra cheese, no mushrooms or olives, and extra green peppers and onions and on the other 1/2 can you make that a pepperoni with double meat. The employee is familiar with the stores menu and does their best to interpret the customers request (which is likely to include many slang terms and lack proper use of grammar) into an order that is based on the stores menu that will lead to the successful making of the pie. In fact, the employee will often restate the order back to the customer for confirmation, such as: Ok, I have you down for a medium hand-tossed pizza; 1/2 will be a supreme with extra cheese, no mushrooms, no olives, extra green peppers and extra onions; the other 1/2 will be a pepperoni with double pepperoni, is this correct? Once the customer confirms the order is correct, the employee responds with the cost and when it will be ready. This can be a time-consuming process and often requires extensive amounts of additional back-and-forth conversation before the order is confirmed by the customer. Also, during peak times, the customer could be placed on hold for an extended period of time or asked to wait because the stores employee is busy at the moment, possibly taking other orders. A pizza franchise owner has several stores. Through research, the owner has determined the labor costs required for monitoring phone calls and taking orders seems disproportionately high and is motivated for a way to cut this cost. The owner has recently decided its time to address the issue, and decides to fund a development effort for a new ordering system for its customers. The owner wants to allow a customer to place a pizza order by calling or texting a phone number representing a store and dialoging (voice/text) with an online ordering system instead of dialoging directly with the stores employee in hopes to reduce (and perhaps eliminate) the amount of time the employee is on the phone taking orders and/or how long a customer has to wait on the phone for the employees availability. However, the owner has expressed a need for the customers ordering experience to appear as if the customer is having a natural-speaking (or texting-style) conversational dialog with the store. In a typical conversation, a customer is likely to order an item that is not actually on the menu, but is understood by the employee as some item on the menu (under a different name). This type of customer experience needs to continue with the new system. The owner values having the system correctly interpret what the customer is saying/texting in their own words/language/dialect instead of forcing the customer to speak using words/language/terms understood by the store. In essence, the system can understand the customer. One final thought from the owner is to keep in mind the customer does not always speak English, thus the new system should take this into consideration as the system evolves. The online ordering system will be privy to the stores menu (items and pricing) so it can correlate the customers request into an order understood by the store. Just as an employee restates the order to the customer for confirmation, so too will the system need to restate the order along with its cost (including any rewards benefits, discounts, and taxes) to the customer for confirmation. Upon confirmation by the customer to place the order, the system will inform the pizza store that an online order has been placed by a customer. The pizza store will be allowed to accept or reject an online order. If accepted, the store can choose to respond to the order with an estimate of readiness, usually in minutes. This response will be noted on the order so that the online ordering system can communicate it to the customer. The store can also flag the order as complete allowing the system to notify the customer their order is ready. Each pizza store has its own menu and pricing. There are several similarities in menu items amongst stores, such as: the ability to order a pizza by the slice or by the pie (a whole pizza); ordering individual items or combination of 2 or more items for a discount; pies having various sizes (ie. small, medium, large, extra-large); pies having various toppings (ie. cheese, pepperoni, sausage, beef, green peppers, onions, mushrooms, olives); pies having various crusts (ie. thin, hand-tossed, deep-dish); pies ordered with toppings that differ on two halves of the pie (ie. has sausage and onions, has beef and mushrooms). Use the following criteria: A customer will need to be able to place a voice call or initiate a text message to a phone number that is not a real store, but rather a gateway to your "new system". If you haven't already done so, you are allowed to make use of the internet as a resource for learning about various technologies that could be utilized for this purpose instead of having to include it in the design of your new system (no need to reinvent the wheel). Your development environments culture is agile, utilizing time-boxed iterations of 15 work-days each. A typical work-day is 8 hours. You are to assume the roles of architect, designer, developer, tester. Due to other commitments, your availability for this product is limited to 65%. Using the epic story described above: Identify the big stories (or themes) to the epic story and how you resolved each of them. Identify at least 10 (more is better) customer user stories. Write each story using index card format which includes a title, brief description, validate/acceptance tests, and assertions/assumptions (as shown in lectures). Keep in mind, there is a dialog occurring between the customer placing an order, a system in the middle acting as the agent for the store, and perhaps several store employees that are involved in "processing" (or fulfilling) the order (though the degree of what it means to "process" and order is not fully spelled out). Ask 3 fellow classmates (limit of 4 to a team, including yourself) to evaluate the individual user stories of each team member, then consolidate stories that are the same. As a team, provide an estimate (total man-days to design, implement, unit test) for each of the teams user stories, thus each story should have 4 estimates. For any estimates considered an outlier, your team, re-estimating as necessary. Try to eliminate assumptions to reduce risk, but for those that cannot be eliminated be sure to account for them. The goal is to reach consensus on the estimates (a small disparity between estimates is tolerable). Also, as a team, prioritize each of the user stories from highest to lowest (as if you are the customer). Provide a plan detailing how to reach the products first release milestone (which is featurebased, unlike each iteration which is time-boxed). Estimate the overall time (in work-days) required to reach the milestone. This first milestone will focus on the cloud-based ordering service from the customer-perspective only and a future release will focus on the storeperspective. The term 'customer-perspective' simply means from the perspective of the customer that places the order for a pizza and will be interacting with a system instead of a store employee, while the term 'store-perspective' means from the perspective of the store that fulfills an order from a customer (placing an order) and will be interacting with a system instead of directly with the customer placing the order. Therefore, don't confuse the term 'customerperspective' with the term 'customer', the two are not the same. The latter is the person(s) representing the company (or product owner) and is an integral player on the team (along with the architect/designer, developer, testers, etc) who defines and prioritizes the user stories. You will be graded based on: The completeness/thoroughness of your plan. 1. A section including a list of all the user stories. Be sure to include assertions, assumptions, and constraints (validation tests) along with the agreed-upon estimate and priority for each story. 2. A section (in paragraph form) describing your rationale for those stories that required multiple rounds of discussion before reaching consensus on an estimate. Also, how you worked to kill any assumptions (how did you tackle them). 3. A section describing the release milestone plan, listing each iteration (starting with 1) and which stories belong to each iteration. Remember, an iteration is limited to 15 work days and should include the highest priority stories from the backlog first. 4. A section (in paragraph form) describing the big stories (or themes) that individual user stories could be grouped under. 5. A section (in paragraph form) describing any remaining assumptions. The validity and correctness of writing user stories according to the criteria discussed in class (and not on the novelty and creativity elements of the product itselfremember your customer writes the requirements; stay away from what you think your customer needs or wants). The accuracy of the estimation provided to reach the products first release milestone