Mobile Aps: Agile Mentoring Review UserStories 1.

13
Mobile Aps: Agile Mentoring Review UserStories 1

Transcript of Mobile Aps: Agile Mentoring Review UserStories 1.

Page 1: Mobile Aps: Agile Mentoring Review UserStories 1.

1

Mobile Aps: Agile Mentoring

Review UserStories

Page 2: Mobile Aps: Agile Mentoring Review UserStories 1.

Concept Graphic

Epics / User Stories / Tasks

EPIC 1

User Story 1

TaskTask

Task

User Story 2

TaskTask

User Story 3

Task Task

Task

EPIC 2

User Story 1

TaskTask

Task

User Story 2

TaskTask

User Story 3

Task Task

Task

Page 3: Mobile Aps: Agile Mentoring Review UserStories 1.

Definitions• Epic - Is essentially a large user story that can be broken down

into smaller related user stories. Sometimes used to describe a block of requirements that have not yet been rationalized into stories.

• User Story - Is a brief statement of a product requirement or a

business case. Most often stories are written in plain language so the reader can understand what the software should accomplish. Product owners typically create stories. A scrum user/team then divides the stories into one or more scrum tasks.

• Tasks – Is a discreet portion of work that is required to finish a story. There are often multiple tasks per user story.

Page 4: Mobile Aps: Agile Mentoring Review UserStories 1.

User StoryCriteria: Simple, brief and concise statements, used to describe customer software requirements, from a particular user’s perspective

Template: As a (_______a_______) I want to be able to (____________b____________), so that (_______c________). In addition, the acceptance of this requirement means that (______d_______)

Page 5: Mobile Aps: Agile Mentoring Review UserStories 1.

User Story (cont.)

Explanation of the Blanks:a) The Person - The role of the user persona in the system

• Fill in the blank with one or more of the following: “user / Product Owner / customer / manager / developer.” Ensure that there is at least one “person” accountable for the use of the developed criteria.

b) Fill in the blank with one or more of the following “action / functionality” - The need expressed by the user persona• Action / Functionality description of what and how the requirement should

work or be when it is donec) The specified requirement is met - The benefit to all stakeholders, such as developers,

users, and others, of meeting the stated requirement• The why aspect addressing the need as description of the final product

d) what “definition of done” is (product owner or requirements SME is owner of story and person to [accept / reject] the finished story)• The description or list of outcomes acceptance criteria of the requirement that

“person” will accept as this item being complete• A clear definition is critical to help remove ambiguity from requirements and

helps the team adhere to quality norms• Helps the team to understand when they are done with the user story

Page 6: Mobile Aps: Agile Mentoring Review UserStories 1.

6

Developing TasksA user story will traditionally be within either a certain time frame or complexity level depending on the team preferences. If a user story needs more than one single piece of work to complete. The story may be broken down into easily identifiable tasks.

Tasks are one single piece of work that contributes to the completion of the story.

• What you are doing by outlining tasks is trying to both avoid surprises by putting any prerequisites to your story in there, (i.e. your story is basically to make a Peanut Butter and jelly Sandwich, but you can put tasks in that describe buying the peanut butter) but also, outlining tasks lets the team know EXACTLY where the story is at the moment or where it stalled.

• You may have a team member that knows nothing about making a Peanut Butter and Jelly Sandwich, but they may know exactly where to buy jelly. If the team sees that your story is hung up because you cannot buy jelly, it makes it very easy and much more likely that this team member can assist you with the least amount of wasted time

Page 7: Mobile Aps: Agile Mentoring Review UserStories 1.

7

Task – Suggested Formats

Page 8: Mobile Aps: Agile Mentoring Review UserStories 1.

8

Acceptance Criteria

• For Scrum• Defines the boundaries of a user story,

and are used to confirm when a story is completed and working as intended.

• A set of statements, each with a clear pass/fail result, that specify both functional (e.g., minimal marketable functionality) and non-functional (e.g., minimal quality) requirements applicable at the current stage of project integration. These requirements represent “conditions of satisfaction.” • There is no partial acceptance: either a

criterion is met or it is not.• Product Owner or Requirements SME

[accepts / rejects]• May be refined throughout the Sprint

• For System Testing:• a test conducted to

determine if the requirements of a specification or system are met

• Verifies the solution works as intended

“definition of DONE” Used for testers – not as a part of Scrum

Page 9: Mobile Aps: Agile Mentoring Review UserStories 1.

9

Format & Examples

• Write the stories in the template format• Tasks are break downs if needed by the team

to divide the work associated with the story

• “Definition of Done” can be refined during the Sprint and written after work starts on it, but must be done by the end of the sprint

• Ensure that there are items listed for the “Definition of Done”• This becomes the acceptance criteria for the

itemExamples:• GOOD As a customer, I want to receive notifications when an incident is

commented, so that I am updated on the status. The acceptance of this criteria means that a push notification is enabled when an incident in commented.

• BAD Notifications are sent when incidents are created.

Each user story should be:• Independent• Negotiable• Valuable• Estimable• Small• Testable

Page 10: Mobile Aps: Agile Mentoring Review UserStories 1.

10

BenefitsBenefits of well developed User Stories:• Help remote teams get clarity• Clearly defined desires of the owner requesting the work or

“person” using the story• They are collaborative and used to level a conversation

• Can be changed or updated at anytime with team consensus• Help enhance communication among the team,

stakeholders, customer, etc.• Remove the need for detailed documentation upfront

Page 11: Mobile Aps: Agile Mentoring Review UserStories 1.

11

Examples• Epic: I want to make a healthy peanut butter and jelly

sandwich

• User Story: As a health conscious eater, I want to be able to use whole wheat bread, so that I can make sure I am getting enough fiber. In addition, the acceptance of this requirement means that a slice of whole wheat bread has a minimum 2 grams of fiber.

Page 12: Mobile Aps: Agile Mentoring Review UserStories 1.

12

Developing Tasks - Example

• If your user story is … “As a worker, I would like to have a homemade Peanut butter and Jelly Sandwich for lunch so that I may eat lunch but save the cost of going out.

• Acceptance Criteria: Must arrive at work with a Peanut Butter and Jelly Sandwich made at home.

The tasks to track may be a version of the following.• Buy Peanut butter (Creamy or Chunky)• Buy Bread• Buy Jell • Spread Peanut Butter onto bread• Spread Jelly onto bread• Put bread slices together• Wrap and bag sandwich

Page 13: Mobile Aps: Agile Mentoring Review UserStories 1.

13

Do you have any questions?