• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Product backlog  stories_acceptancecriteria_size_priority
 

Product backlog stories_acceptancecriteria_size_priority

on

  • 3,336 views

 

Statistics

Views

Total Views
3,336
Views on SlideShare
3,318
Embed Views
18

Actions

Likes
10
Downloads
177
Comments
1

2 Embeds 18

http://www.slideshare.net 17
http://www.lmodules.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • thank you so much I have been on a course which was good but a bit of a whirl-wind and now I am currently working on a project some time after my two date course i needed something that really put all the info in place
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Product backlog  stories_acceptancecriteria_size_priority Product backlog stories_acceptancecriteria_size_priority Presentation Transcript

    • Delivering value early and often, giving ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can use to help us improve Copyright © 2008 Russell Pannone. All rights reserved.
    • Product Backlog  Stories at the right level of detail  Prioritizing stories  Sizing stories  Deriving/estimating duration to deliver product  Committing to schedule to deliver product Copyright © 2008 Russell Pannone. All rights reserved. 2
    • How to Organize a Children's Party
    •  Chaotic System-Software Development Environment  Ordered System-Software Development Environment  Complex System-Software Development Environment Copyright © 2008 Russell Pannone. All rights reserved. 4
    • Five (5) “whys” analysis applied as an effective reflective technique in the world of “being” agile and lean 1. Why is our Product Owner, unhappy? Because we did not deliver the product release and business value when we said we would 2. Why were we unable to meet the agreed upon timeline or schedule for delivery? The product took much longer to develop than we thought it would 3. Why did it take so much longer? Because we underestimated the complexity and uncertainty of the stories 4. Why did we underestimate the complexity and uncertainty? Because we did not have acceptance criteria associate with each story, our stories were not at the right level of detail and we did not realistically size each story prior to committing to a schedule for delivering the release 5. Why didn't we do this? Because the higher powers were still working under the traditional waterfall planning mental-model, as a result we felt pressure to work faster and skipped steps  Solution: We clearly need to review and improve our approach to writing stories, prioritizing stories, sizing stories, deriving/estimating duration and committing to a schedule for delivering the product >>>>> Then get buy-in and visible support from the higher powers Copyright © 2008 Russell Pannone. All rights reserved. 5
    • Scrum Framework Copyright © 2005, Mountain Goat Software 1. Agile puts the Product Owner (aka “the business” or customer representative) in the driver’s seat – In the majority of the waterfall style projects the customer is involved, but in a limited capacity. They get to define a scope up-front, but then any changes they deem necessary are change ordered back to them. This practice assumes that the customer knows exactly what they want up front and penalizes them for changing their minds later in the development process. 2. Agile allows the business to quickly react to changing market conditions and needs – The only thing constant in today’s economy is change. Businesses need to be able to make quick course corrections in order to survive. 3. Agile provides visibility into the development process – For many customers software development is a dark art. They don’t have the background in order to understand the technical details and in most cases the development team prefers it this way. The customer is left feeling helpless and Agile engages them throughout the development lifecycle, providing enhanced visibility. 4. Agile also puts the Development Team in the driver’s seat - While the Product Owner is responsible for “what” is to be developed the Development Team is self-directing and self-organizing as to “how” to develop the system- software product Copyright © 2008 Russell Pannone. All rights reserved. 6
    • Copyright © 2008 Russell Pannone. All rights reserved. 7
    • Roles •Product owner Scrum Framework •Team •Scrum Master Ceremonies •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artifacts •Product backlog •Sprint backlog •Burndown charts Copyright © 2008 Russell Pannone. All rights reserved. 8
    • Scrum Explained “The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.”- Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986 In Scrum you work in iterations delivering value-adding results incrementally Copyright © 2008 Russell Pannone. All rights reserved. 9
    • 1. Selecting Stories from the Product Backlog based on the team’s velocity 2. Identifying the tasks to realize a selected Story 3. Estimating the level-of- effort required to complete the task Copyright © 2008 Russell Pannone. All rights reserved. 10
    • 1. Performing tasks to complete the story 2. Completing the story based on story acceptance criteria and team's definition of done Copyright © 2008 Russell Pannone. All rights reserved. 11
    • Where do Optional Stories come from Optional Optional Bus Strategy Use Cases Business Model System Requirements Functional Customer & Business Partner Non-Functional Product Owner Solution/IT-Services Copyright © 2008 Russell Pannone. All rights reserved. 12
    • Characteristics of good stories As a <who> I want <what> so that <why>  A good story is negotiable, testable, estimatable, commercially or operationally value-adding, cohesive and loosely-coupled  It is not an explicit contract for features or functionality; rather stories are short descriptions of functionality, the details of which are to be refined in a conversation between the Product Owner (aka, the business or customer) and the development team  The challenge comes in learning to include just enough detail to be able to prioritize and estimate the size of story and minimize ambiguity Story1 Story4 As an eligible user, I want to pay the As an eligible user, I want to access my Story11 onetime registration fee of $10, so record and delete any or all of my As an eligible user, I want to view a list that I can access my driver’s record in information to keep it current of assembled answers to questions the future asked most frequently of the DMV Story5 Story2 Story12 As an eligible user, I want to access my As an eligible user, I want to create a As an eligible user, I want to be able record and change any or all of my unique user name and password so find an address for my local DMV information to keep it current that my access is limited to my record office and print the results and to track activity and payment Story6 Story13 Story3 As an eligible user, I want multiple As the application, I want to maintain As an eligible user, I want to access my payment options to pay fees so that I an audit trail of changes for each record, so that I can verify that it is am able to access the features of the eligible user record indicating all edits correct DMV site that require payment Copyright © 2008 Russell Pannone. All rights reserved. 13
    • Story Size  The fact of the matter is some stories can be too big, some can be too small, and some can be just right  Stories that are too big are called Epics  Epics are difficult to work with because they frequently contain multiple stories  Epics typically fall into one of two categories:  The compound story  The complex story Story As an eligible user, I want to access my record, so that I can verify that it is Epic (compound story) correct As an eligible user, I Story As an eligible user, I want to access my want to view , add, record and delete any or all of my information, so that I can keep it change or delete my current DMV information so that Story As an eligible user, I want to access my I can keep it current record and change any or all of my information, so that I can keep it current Copyright © 2008 Russell Pannone. All rights reserved. 14
    • Complex Story  Unlike the compound story, the complex story is a story that is inherently large and cannot easily be disaggregated into a set of constituent stories  If a story is complex because of uncertainty associated with it, you should estimate the size of the story at the highest range of your estimating scale (1, 2, 3, 5, 8, 13, 21, 34)  Then prior to the sprint where you are going to pull it in have an investigate story to more clearly understand what the solution involves to deliver this story Epic (complex story) As an eligible user, I want multiple payment options to pay my fees so that I am able to access the features of the DMV site that require payment For example, suppose the team is given the story depicted above, but none of the developers has ever done credit card processing before. The team would then decide to disaggregate the story like this: • Investigate credit card processing over the web • A user can pay with a credit card In this case the first story will send one or more developers on a spike. When complex stories are split in this way, always define a time-box around the investigative story, or spike. Copyright © 2008 Russell Pannone. All rights reserved. 15
    • Meeting the Product Owner’s Conditions-of-Satisfaction  Outside-In-Design > One of the key characteristics that make stories so fitting for delivering value early and often is that they focus on describing the source of value to the Product Owner, instead of the mechanics of how that value is delivered  Stories strive to convey the Product Owner wants and needs, the who, what and why and not the specifics of the solution or the details about how the team will implement the story  Acceptance criteria is used at the end of a Sprint/Iteration, when demonstrating to the Product Owner what the team has implemented  Acceptance criteria is used to guide the team’s definition of “done” for a story  A story is not considered complete or “done” until the acceptance criteria/conditions-of-satisfaction have passed Copyright © 2008 Russell Pannone. All rights reserved. 16
    • Acceptance Criteria  Acceptance criteria, represents the details for a story and specifies the desired behavior and functionality the system-software must implement  Acceptance criterion is high level tests to verify and validate the completeness of a story or stories implemented during a Sprint/Iteration, expressed in a business domain language  These tests are created ideally through collaboration between business customers, business analysts, testers and developers; however the Product Owner (aka, the business or customer) is the primary owner of these conditions-of-satisfaction Copyright © 2008 Russell Pannone. All rights reserved. 17
    • Formulating Acceptance Criteria  We should try to formulate acceptance criteria in terms of the goal of the story and leave the solution up to the developers and the Product Owner to decide and discuss at a later time, during Sprint Planning and a Sprint; when we’re validating and verifying the acceptance criteria and implementing the story itself As an eligible user, I want to pay the onetime registration fee of $10, so that I can access my driver’s record in the future 1. Verify that a payment can be made 2. Verify that once a payment is made, the user can view their record (with any subsequent fees) 3. Verify that payment option is not available if registration has already been paid As an eligible user, I want to create a unique user name and password so that my access is limited to my record and to track activity and payment 1. Verify that a user account can be created 2. Verify that a user name that is already in use (assigned) is not accepted and the user notified then prompted for a different user name 3. Verify that the user name conforms to naming convention (length, caps, etc.) 4. Verify that the password conforms to naming convention (length, caps, symbols, etc.) 5. Verify the generation of correct error messages when the user attempts to enter invalid data 6. Verify appropriate action is taken if the data entered is invalid 7. Verify that the legal compliance conditions and consequences of use are displayed and accepted As an eligible user, I want to access my record, so that I can verify that it is correct 1. Verify that the user’s record is displayed 2. Verify that the user cannot access records other than his/her own (or dependents) 3. Verify that user is charged $10 for the first access and $5 for subsequent accesses 4. Verify that the user is limited to three record accesses each year 5. Verify that the system displays user profile information including names, addresses, email addresses, credit cards, and PayPal 6. Verify that records for any nonresident individual with a driving record in the state can be accessed Copyright © 2008 Russell Pannone. All rights reserved. 18
    •  Depiction of the user interface or maybe even a report layout, is just as much a part of the details behind a story as acceptance criteria  Wireframes and screen mockups are often attached to stories as a basic visual guide used in interface design by the development team  Low fidelity diagrams depicting a candidate solution may also be attached to stories to visually communicate its design Copyright © 2008 Russell Pannone. All rights reserved. 19
    • Five factors to consider when prioritizing 1.The commercial or operational value of the delivered story 2.Degree of uncertainty - the amount and significance of learning and new knowledge gained by developing the story; focused on requirements and technology 3.The amount of risk removed by developing and delivering the story – focused on schedule, budget, scope, operation, technology 4.Dependencies – stories that must be developed together and are delivered together to provide value to the customer 5.The cost of developing and delivering the story Copyright © 2008 Russell Pannone. All rights reserved. 20
    • Story Prioritizing Exercise 21
    • User Stories Business Story Points Priority Story A 1 5 Story B 2 8 Story C 3 1 Story D 4 8 Story E 5 2 Story F 6 2 Story G 7 2 Story H 8 8 Story I 9 5 Story J 10 1 Copyright@ 2008 Russell Pannone. All rights reserved. 22
    • Story Points: Relative Measure of the Size of a Story Copyright © 2008 Russell Pannone. All rights reserved. 23
    • Copyright © 2008 Russell Pannone. All rights reserved. 24
    • Story Sizing Exercise 25
    • Backup Slides
    • Copyright © 2008 Russell Pannone. All rights reserved. 27
    • Work Que (Kanban) Pending WIP Done Story Story Story Story Story Story Define Story Story Story Story Story Story Story Story Story Story Story Story Story Story Story Build & Story Test Design Implement Story Story Story Story Story Story Story Story Story Story Story Story Code Story Story Copyright © 2008 Russell Pannone. All rights reserved.