This assignment has three parts:
1. When you developed your product Roadmap, you identified a few key areas to develop in sprint timeblocks. These may correspond to good Themes for your project. Think this over. Are these Themes? Can you think of a better way to organize your project into Themes? Decide on at least THREE specific Themes for your project. Give them a name and BRIEF ( a sentence or two) description to clarify what they generally include.
2. Take ONE of your Themes. Identify TWO Epics and state them in the story template format. Your Epics do not need to cover the entire theme, but it must be clear that they are part of the Theme.
3. Take ONE of your Epics. Identify TWO final User Stories for it. They do not need to cover the entire Epic, but it must be clear that they are a part of the Epic. State each in formal User Story format. Develop a comprehensive set of Acceptance Criteria for each.
You can present these in any way that you like, you don't have to try and fit things onto "cards". A simple, well-organized Word document will be fine. Just be sure I can see how you have organized the components.
Depth of Thought:
This will include how well you have decomposed the components, and how clearly your themes reflect themes, your Epics demonstrate Epics, and stories demonstrate stories. It includes how thoroughly you have identified and clearly stated the Acceptance Criteria.
Project Start Up From Story to Theme and back again How to discover your requirements What Requirements problems do User stories address? Communications! Software requirements is a communication problem Those who want the software must communicate with those who will build it Tech-types and end-user managers don’t speak the same “language” Balance! If the business side dominates the discussion, functionality and dates are mandated with little regard for reality or whether the developers understand the requirements. If the developers dominate, technical jargon replaces the language of the business and developers lose the opportunity to learn from listening ( a KEY SKILL in IT development) What Requirements problems do User stories address? Responsibility Tech staff may solely make decisions that should involve the business Lengthy upfront requirements negotiation and signoff Features (or quality) can be progressively dropped as the deadline nears. Important business value may be sacrificed. Imperfect expectations and schedules We cannot perfectly predict a software schedule As users see the software, they come up with new ideas and expect them delivered! Too many intangibles Developers have a notoriously hard time estimating If we can’t perfectly predict a schedule, we can’t perfectly say what will be delivered So what do we do? Spread decisions based on the information we have as we go Do this often! Product Owner driven! Focus on BUSINESS value ( who, what and why, not how) BEGIN the conversation about detailed requirement with User Stories. User Story Examples AS a Corporate traveler I WANT to book a room near my client SO THAT I will have a place to stay before my business meeting AS a Vacation traveler I WANT to see photos of the hotels SO THAT I can pick one that I like AS a traveler with interrupted plans I WANT to cancel my reservation SO THAT I won’t be charged a no-show fee AS a frequent traveler I WANT to store my room preferences SO THAT I don’t have to keep entering them every time I travel. AS a frequent traveler I WANT to have discounts when I book a room for many days SO THAT I feel like a valued customer and can save money The Three C’s Index cards or similar Add notes, estimates, value Be brief but consistent Card Details behind the story come out during conversations with product owner Conversation Acceptance criteria used to confirm a story is “done” (fully tested) Confirmation What is the conversation? Details to work out: Does the user get a full or partial refund for any advance payments/deposits? Does a refund go to the original credit card or is it a credit for a future booking? How far ahead must the reservation be cancelled? Is the policy the same for all hotels? Is a confirmation provided to the user? How should the confirmation be made? What happens when no cancelation is received for a no-show? (Hey, do I need another User Story for this? ) AS a traveler with interrupted plans I WANT to cancel my reservation SO THAT I won’t be charged when I don’t show up Confirmation using Acceptance Criteria Acceptance criteria: Does this story meet the definition of DONE? ◻︎ The product owner’s conditions of satisfaction These are essentially the Test Cases Verify that cancelations more than 24 hours in advance get a full refund sent to the credit card used for booking Verify that same-day cancellations get a 90% refund sent to the credit card used for booking. Verify that an email confirmation with the refund amount is sent to the email used for the original booking Verify that the hotel is notified of any Cancellation within 10 minutes of when it is received 8 Evolving User Stories – more conversation AS a traveler I WANT to know the cancelation rules when I book a room SO THAT I will know what to expect if I have to cancel AS a traveler with interrupted plans I WANT to cancel my reservation SO THAT I won’t be charged a no-show fee AS A business club member, I WANT to cancel a reservation at the last minute with no penalty SO THAT my business plans can be more flexible AS A canceling traveler, I WANT to get an email confirmation of my refund information SO THAT I can have a record of the refund for checking my credit card transactions Details added in even ”smaller” stories! Product BAckLog Theme Epic Story Story Epic Story Story Story Story Story Story Story Priority Examples of Epics AS a VP Marketing, I WANT to review the performance of historical promotional campaigns SO THAT I can identify and repeat profitable ones. AS a VP Marketing, I WANT to select the timeframe for reviewing the Promotion Campaign performance SO THAT. … As a VP Marketing, I WANT to select which type of campaigns (direct mail, TV, email, radio, etc.) for reviewing performance SO THAT… DEFINITELY AN EPIC! Maybe EPICS?? Includes whole team ( but definitely the Product Owner) plus possibly some external stakeholders Brainstorm to generate stories Goal is to write as many stories as possible Some will be “implementation ready”, others will be epics No prioritization at this point Story Writing “workshops” DON’t forget the main purpose The story text we write on cards is less important than the conversations we have about them!