Copyright Robert W. Hasker

Story Review  Elements of a Scrum story:  The three C’s:  Sprintable stories:  Mechanisms for obtaining stories:

Story Review  Elements of a Scrum story:  As a, I want to because.  Acceptance criterion – when stakeholder satisfied  The three C’s:  Sprintable stories:  Mechanisms for obtaining stories:

Story Review  Elements of a Scrum story:  As a, I want to because.  Acceptance criterion – when stakeholder satisfied  The three C’s:  Card, Conversation, Confirmation  Sprintable stories:  Mechanisms for obtaining stories:

Story Review  Elements of a Scrum story:  As a, I want to because.  Acceptance criterion – when stakeholder satisfied  The three C’s:  Card, Conversation, Confirmation  Sprintable stories:  INVEST  Mechanisms for obtaining stories:

Story Review  Elements of a Scrum story:  As a, I want to because.  Acceptance criterion – when stakeholder satisfied  The three C’s:  Card, Conversation, Confirmation  Sprintable stories:  INVEST  Mechanisms for obtaining stories:  User-story-writing workshop, story mapping

Stories vs. Requirements RequirementsStory Form Detail Size Readiness check Estimation How to handle errors?

Stories vs. Requirements RequirementsStory Form “as an X, I want to Y so that Z” Detail Story can be a promise to discuss a topic w/ customer. Size Can vary from epic to requirement. Readiness check INVEST Estimation How to handle errors?

Stories vs. Requirements RequirementsStory Form“shall”“as an X, I want to Y so that Z” DetailAnything not said is not done – forms a contract Story can be a promise to discuss a topic w/ customer. SizeEach requirement has small scope Can vary from epic to requirement. Readiness checkReview by customer, written tests INVEST EstimationDays of person-effortStory points How to handle errors?Rework or renegotiateAdd to backlog

Good stories I N V E S T

IIndependent NNegotiable VValuable EEstimatable SSmall (appropriate size) TTestable

Good stories IIndependent NNegotiable VValuable EEstimatable SSmall (appropriate size) TTestable Why?

Contradiction  Early on: a story should be a placeholder and real requirements are captured during the sprint.  Later: a story must meet the INVEST criteria  Our model: stories must meet INVEST to be in the sprint  Must know how to take story out before put it in.  Write use case for each story – can be short, but capture exceptions.

Examples  As an MSOE faculty member, I would like the kiosk to be branded so that it looks like a part of MSOE.

Examples  As an MSOE faculty member, I would like the kiosk to be branded so that it looks like a part of MSOE.  The site looks a little bit "off". We need to update the CSS so that it looks like the hub at least for the navigation portion. Spacing, fonts, and link colors are all incorrect.

 As an admissions counselor, I would like to have most of the info available at a glance because I don't have time to click around during a tour.  Conditions of Satisfaction: Do not need to scroll to view most information

 As an admissions counselor, I would like to have most of the info available at a glance because I don't have time to click around during a tour.  Change the default settings in the graph to start at daily, then go to weekly, and then go to monthly and so on.  Provide clear definitions of the data and how it is calculated in text.  The temperature widget has not been displaying the correct temperature. Find the issue and correct it.  Make sure the graph is displaying the correct information and in the correct scope.

 As a user, I want to view a GUI while using the system so that the system is easier to navigate.  (Decide how to organize the UI and create the UI elements.)

 As a user, I want to view a GUI while using the system so that the system is easier to navigate. Create a page to display the status of a room for the application. Create the login screen for the UI Build the control fragment used to move between pieces of application functionality. Buttons needed for room status, room calendar, partner calendar, create appointment, and room list. Create a fragment that displays a form for entering appointment data which includes: date, start/end date, attendees, etc. Create the main activity and integrate the different pieces of the application through method calls. Create the room list fragment that will display the room status of the other rooms. Design, create, and test the UI for the calendar fragment. Implement the login button in the status bar of the application and link it to the login page. Create a button for the room status. The user needs to be able to navigate back to the main screen of the application.

A more positive example  As a website user, I want double-clicking on the hourly performance data chart to leave the user in the hourly view so an accidental double-click doesn't jump me to a view that's unrelated to my intent.  Acceptance criteria: Change to performance view, navigate until hourly data is showing, double-click on the hour bar, and confirm no change to the performance view.

 As a user, I want there to be a "room status" screen so that I can see whether the room is available or not at a glance.  (Create a room status screen.)

 As a user, I want there to be a "room status" screen so that I can see whether the room is available or not at a glance.  (Create a room status screen.)  Find the next available half hour block and display through the UI  Implement and test the next meeting functionality on the room status screen.  Implement the getting of the room's schedule and determining whether the room is currently available or not.

Review  Story review  Stories vs. requirements  INVEST  Examples