Backlog Management & Discovery
- 2. What is Agile? • Agile is an umbrella term which has lot of approaches that enables us with growth mindset and creating a culture where we respond to change over reacting • Change is constant • It is inversely proportional to inertia • It helps us in shortening the feedback loop • Intent is to fail or succeed faster • Power of just-enough • Progressive elaboration
- 5. Just-enough Mindset • Let’s learn ‘bite of a burger’ concept ☺ • What happens when you take the first bite? • We need to learn on how to limit our expectation and find out a way to create minimum outcome which can create maximum impact so as to fail faster by shortening the feedback loop
- 6. Project Progress in SCRUM Project Start Project End Sprint Sprint Sprint Sprint Sprint Sprint “Definition of Done” is the key
- 7. Example: Online Shopping Experience AUTHENTICATE
- 8. Mapping different Phases in Sprints Release planning Gate – Release1 Requirement Approval Gate – Release 2 Requirement Approval Gate – Release 1 Release planning Gate – Release 2 Gate – XXX Gate YYY Requirement Phase Elaboration phase Assessment Phase Pre-Construction, Construction & Validation phase Post validation phase US 7.4 Product Epic 8 US 7.5 Product Epic 1 Product Epic 2 Product Epic 1 US 1.1 US 1.2 Product Epic 3 Product Epic 7 Product Epic 8 Product Epic 7 Product Epic 7 US 8.2 US 8.3 US 3.3 Product Epic 8 Product Epic 3 Product Epic 4 Product Epic 5 Product Epic 6 Product Epic 9 Product Epic 10 Product Epic 3 Product Epic 4 Product Epic 11 Product Epic 12 US 4.1 US 4.2 US 3.1 US 3.2 Product Epic 13 Product Epic 14 Product Epic 2 Product Epic 11 US 3.4 US 3.5 Product Epic 6 US 7.1 US 7.2 US 7.3 US 8.1 Product Epic 6 US 6.1 US 6.2 Product Epic 1 1 2 7 8 6 3 4 5
- 9. An Umbrella of Approaches & its Practices An approach where typically requirements & solutions evolve through collaboration of cross functional teams. Agile is NOT a standard…. It’s collection of practices which are • Upheld by Values • Guided by Principles • People Centric • Self Organizing • Value Driven • Collaborative • Servant Leadership An umbrella term for several iterative and incremental software development methodologies.
- 10. Planning & Backlog Mgmt • Planning for a Release Increment • Discovery Session • Story Mapping • Personas, user stories, epics, themes • Estimation • Release Planning
- 12. Bringing it all together
- 13. What we want?
- 14. Let’s start with DISCOVERY SESSION
- 15. Let’s start with DISCOVERY SESSION Collect the Ideas Goal setting Persona Mapping User journey Story Mapping MVP identification Now - Next - Later Story writing Writing Epics Writing User stories & Tasks Prioritization Identifying Themes Value & Risk MoSCoW ROI Differentiator, Spoiler, Table Taker, Organizational cost Estimation Scope, Cost & Time Story point estimation Base story definition Dependencies & Risks Timeline View Sprint Zero expectations
- 16. Goal Setting & Persona Journey
- 17. Goal Setting & Persona Journey
- 18. Story Map – Collaborate to create
- 19. Walking Skeleton
- 23. Start with EPICS ● Epics are big, coarse-grained user stories. Starting with epics allows you to sketch the product functionality without committing to the details. ● This is particularly helpful for new products and new features: It allows you to capture the rough scope, and it buys you time to learn more about the users and how to best meet their needs. ● It also reduces the time and effort required to integrate new insights. If you have lots of detailed stories, then it’s often tricky and time-consuming to relate any feedback to the right stories.
- 24. Decompose your Stories until they are Ready Break epics into smaller, detailed stories until they are ready: clear, feasible, and testable. Everyone should have a shared understanding of the story’s meaning; the story should not be too big, and there has to be an effective way to determine if the story is done. As one decomposes epics into smaller stories, Acceptance criteria complement the story’s narrative: They allow to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story and make it more precise and testable, and they ensures that the story can be demoed or released to the users and the other stakeholders. As a rule of thumb, use three to five criteria for detailed stories. Tests - The goal is to convey additional information about the story so that the developers will know when they are done.
- 25. User Persona Creation What is a User Persona? ∙ A Typical user of the system ∙ Start with provisional personas – using market insights, direct observation and problem interviews ∙ Choose a Primary persona – the character you design and build the system for ∙ Test your personas – by building prototypes, product increments, MVPs ∙ Connect Personas and User stories – the primary persona should be the protagonist in the user stories ∙ Visualize your personas ∙ Personas may not be necessary for all situations
- 26. Writing Requirements Effectively – User Stories ∙ User Stories are a short, plain-language description of the features, in terms of customer value ∙ User Stories are centered around the customer and what they need to do ∙ They are structurally simple and provide a great placeholder for a conversation ∙ They can be written at various levels of granularity and are easy to progressively refine
- 27. User Stories - Card ● Acceptance Criteria ● • • • Notes ● • • • • … … Back of the Card “As a user, I want to pay for items in my shopping cart using a credit card, so that I can have them shipped to me”
- 28. User Stories - Conversation ● The card only covers the most basic information ● The next level of detail comes in conversations between the Product Owner and the Team ● The conversations take place • At project start, during story-writing sessions • During the Backlog Refinement Meeting • During the Sprint Planning Meeting • During the Sprint
- 29. User Stories - Confirmation ● Accepts Visa, MC, AmEx and rejects other types of card • Rejects invalid card number or expired card • Accepts different dollar amounts • Rejects amount higher than the card limit
- 30. Example : Travel Reservation System As a user, I can reserve a hotel room. As a vacation planner, I can see photos of the hotel As a frequent flyer, I want to rebook a past trip so that I save time booking trips I take often As a user, I can cancel a reservation
- 32. Create Incrementally i.e. MVP
- 33. How to split?
- 34. It’s a funnel
- 35. Splitting Stories Epics typically fall into following two categories: The compound story • It comprises of multiple shorter stories • Example: A customer can plan a vacation (in a travel reservation system) The complex story • A story which is inherently large and cannot easily be disaggregated. It is called complex because of uncertainty associated with it. • In such cases split it into two stories: Investigative and development • It is recommended to define a Spike around the investigative story.
- 36. At times it may become necessary for us to split the user stories into smaller stories: • When it is difficult to fit a user story in a single iteration • When there is not adequate time to fit the story in the current iteration, though it may be small • When there are operational requirements (like performance or any other non functional specification) • Split stories based on CRUD operations • When the story is too big even to estimate • Do not try and split stories into tasks / activities When to Split User Stories
- 37. I Independent : Dependencies between stories make planning, prioritization, and estimation much more difficult. N Negotiable: A user story is negotiable V Valuable: Each story has to be of value to the customer (either the user or the purchaser). E Estimate-able: The developers need to be able to estimate (at a ballpark even) a user story to allow prioritization and planning of the story. S Small: A good story should be small in effort, typically representing no more, than 2-3 person weeks of effort. T Testable: A story needs to be testable for the "Confirmation" to take place. How to Evaluate a Good Story INVEST
- 38. How to Slice?
- 39. ● Workflow Steps ● Business Rule Variations ● Major Effort ● Simple/Complex ● Variations in Data ● Data Methods ● Defer System Qualities ● Operations ● Use Case Scenarios ● Break Out a Spike Splitting User Stories : Typical Attributes
- 40. Splitting User Stories by Operational Boundaries • As a marketing representative I want to manage the online catalogue so I can ensure our customers can purchase our products. – As a marketing rep I want to create an item in the catalog so I can ensure our customers can see and purchase our new products. – As a marketing rep I want to read the list of items in the online catalog so I can ensure our customers can see our current product list. – As a marketing rep I want to update items in the online catalog so I can ensure our customers have the most up to date info. on our products. – As a marketing rep I want to delete items from the online catalog so I can ensure our customers do not see or order discontinued items.
- 41. Splitting User Stories by Data Boundaries • As a Financial Analyst I want to enter balance sheet data so I can maintain year wise financial information. – As a Financial Analyst I want to enter Summary balance sheet data so I can get consolidated information. – As a Financial Analyst I want to enter Categorized balance sheet data so I can view data in various categories . – As a Financial Analyst I want to enter Detailed Asset information so I can see the breakup of asset information. Splitting by Priorities. •As a user I want to login so I can work with my account data. – As a user I want to have unlimited login attempts so I can work with my account data. – As a user I want to be denied access after 3 failed login attempts so my account information is protected. – As a user I want to receive emails when access is denied to my account so I’m aware of attempts being made to access my account.
- 42. Identify specific steps that a user takes to accomplish a workflow, then implement the workflow in increments. As a utility, I want to update and publish pricing programs to my customer... ...I can publish pricing programs to the customer’s In-Home Display ❖ ...I can send a message to the customer’s web portal ❖ ...I can publish the pricing table to a customer’s smart thermostat Splitting User Stories by Workflow Steps
- 43. Business rule variations often provide a straightforward splitting scheme As a utility, I can sort customers by different demographics... ...sort by zip code ...sort by home demographics ..sort by energy consumption Splitting User Stories by Business Rule Variations
- 44. Split by type of operation example: Create Read Update Delete (CRUD)… As a user, I can manage my account... • ...I can sign up for an account. • ...I can edit my account settings. • ...I can cancel my account. • …I can add more devices to my account Splitting User Stories by Operations
- 45. If use cases are used to represent complex interaction, the story can be split via the individual scenarios As a user, I can enroll in the energy savings program through a retail distributor ... • Use Case/Story #1 (happy path): Notify utility that consumer has equipment • Use Case/Story #2: Utility provisions equipment and data, notifies consumer • Use Case/Story #3 (alternate scenario): Handle data validation errors Splitting User Stories by Use Case Scenarios
- 46. What if the base use case is too big? Use the heuristics in the graphic below Techniques for slicing
- 47. In some cases, a story may be hard to estimate may be too large or overly complex or perhaps the implementation is poorly understood In that case, build a technical or functional spike to figure it out; then split the stories based on that result. Split – If All Else Fails, Break out a Spike Technical Spi ke Functional Spik e
- 48. Epic & User Stories Story Writing Session Epic Name Story Id As a I want So that Acceptance Criteria Assumptions A A.1 A A.2 A A.3 A A.4 B B.1 B B.2 B B.3
- 49. Story Prioritization – MoSCoW Model MoSCoW is a prioritization method and assists teams to organize storycards according to the value from the customers perspective. The story cards are organized into four categories: M | Must have this attribute or feature; a non-negotiable S | Should have this attribute or feature; should be included if possible C | Could have this attribute or feature; less critical, “nice to have” W | Won’t have; least critical, lowest value or ‘would like to have in the future’ MuSCoW Technique
- 50. Story Prioritization – Value Driven Do firstAvoid Do last Do second Low High Value Low High Risk
- 51. Story Writing Prioritization Epic Name Story Id As a I want So that Acceptance Criteria Assumptions MoSCoW Value Point Risk Point A A.1 A A.2 A A.3 A A.4 B B.1 B B.2 B B.3 Story Prioritization – Template is evolving
- 52. Estimation
- 53. Sizing in Scrum – Story Points • Sizing in Scrum is performed using STORY POINTS • Sizing using story points is a relative concept, It is unit less in nature • A user story estimated as 10 story points is twice as big or risky as a story estimated as 5 story points • What matters are the relative values assigned to a different stories How long will it take to do How difficult will it be to do How unsure are we of the requirements or implementation SIZE = Effort x Complexity x Uncertainty • Everyone estimates the whole size (design, code, test, etc.)
- 54. Velocity • Velocity measures output (the size of what was delivered), not outcome (the value of what was delivered) • Velocity is the amount of work completed in each sprint • Measured by adding the sizes of stories delivered in the sprint • Doesn’t include work partially delivered • Server two important purposes • Used for planning • Team’s commitment in a sprint
- 55. Value Sample Meaning 0 No Effort required 1 Extra Small 2 Small 3 Medium 5 Large 8 XL 13 XXL 20 Not doable in a Sprint 40 Spans multiple sprints 100 Throughout the Release ? … Need more information Based on Fibonacci sequence, a recurring organizational pattern The story point scale has no statistically reliable relationship to man hours Typical parameter to consider : Complexity, Uncertainty, Effort involved, Dependencies etc Story Point – Scale
- 56. Estimation Techniques – Story Point Estimation
- 57. Simultaneously , each person shows estimate Ea ch person chooses their es timate People with high & low estimates explain their reasoning Team discusses User Story Until the number s are clos e Story Points Estimation with Planning Poker
- 58. Backlog template Story Writing Prioritization Estimation Epic Name Story Id As a I want So that Acceptance Criteria Assumptions MoSCoW Value Point Risk Point Story point A A.1 A A.2 A A.3 A A.4 B B.1 B B.2 B B.3
- 59. Finding the IRON Triangle
- 60. Release Planning Exercise Scenario 1: A team has an average velocity of 24 story points. The product backlog contains 75 stories.. 40 Must have, 20 Should have & 15 Could have Size of the product backlog is 256 story points. How many iteration will take take ideally? Now, we are adding the buffer of 35% over the backlog, then how many iterations are we going to take? Scenario 2: Lets say, management wants to know how much time will be take to finish all the Must & Should stories? <velocity is 24 sp, buffering% remains same> After some time, the velocity went down to 17 sp, now how many iterations are you going to take?
- 61. THANK YOU Anuj M Ojha www.Benzne.com