Presentation is loading. Please wait.

Presentation is loading. Please wait.

Mobile Aps: Agile Mentoring Review

Similar presentations


Presentation on theme: "Mobile Aps: Agile Mentoring Review"— Presentation transcript:

1 Mobile Aps: Agile Mentoring Review
UserStories

2 Concept Graphic Epics / User Stories / Tasks EPIC 1 EPIC 2
User Story 1 User Story 1 User Story 2 User Story 3 User Story 3 User Story 2 Task Task Task Task Task Task Task Task Task Task Task Task Task Task Task Task

3 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.

4 User Story Criteria: 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_______)

5 User Story (cont.) Explanation of the Blanks:
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. 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 done 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 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

6 Developing Tasks A 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

7 Task – Suggested Formats

8 Acceptance Criteria For Scrum For System Testing:
“definition of DONE” Used for testers – not as a part of Scrum 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

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 item Each user story should be: Independent Negotiable Valuable Estimable Small Testable Examples: 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.

10 Benefits Benefits 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

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.

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

13 Do you have any questions?


Download ppt "Mobile Aps: Agile Mentoring Review"

Similar presentations


Ads by Google