Project to Product - who, when, what and how ?

Transcript

1. Project to Product Journey Aug, 2020 Chandi Kodthiwada
2. Path to Project-Kickoff Recruit the Team: Stack the deck! Grow the Team Work w your Partners early on – while contract creation process! Get on the same page w Business Create an Outcomes view for Business Establish a Process, Cadence, Tools Do as much as you can before growing the team but get input Get your Release Backlog ready! Size, Prioritize, Refine & Socialize Get your Spike work in Sprint 0 – get your infrastructure, software and licensing figured out and the research you’ll need
3. Partners Product Groups Business Development, TCoE, VCoE, UAMS Core Product Team Business Partner, Product Manager, Business Analyst, Scrum Master, Product Engineer • Product Manager • Scrum Master/Project Mgr. • Product Engineer • Business Lead(s) • Dev Lead (Partner) • TCoE Lead • VCoE Lead • UAMS Lead Business Partner + Recruit the Team in that order
4. Intended Outcomes for Business Outcome driven prioritization Early and Often: Demos/reviews & feedback Continuous: Requirement Refinement & Learning (Retro) Greater Transparency into Outcomes per Sprint & Release
5. So what does the Process look like? 14-21 days 24 hours Release Backlog T-shirt sized, prioritized backlog that you hope to accomplish in a time-boxed exercise (usually with a historically known Release capacity) Sprint Backlog The Team reviews the Product Backlog Stories with the Product Owner and accepts a set of these stories into the sprint creating the Sprint Backlog. Daily Scrum A 15-min daily meeting: • What I did since the last scrum? • What am I planning to do today? • Do I have anything preventing me from accomplishing my goals? Working increment of the product Sprint Review The Team demonstrates completed “done” stories to the Product Owner both during the Sprint and at the Sprint Review. At the Sprint Review the Product Owner either accepts this completed work or redirects the Team for the next Sprint. Sprint Retrospective The Team then conducts a Sprint Retrospective to review this last sprint to determine process/team improvement options. Sprint Execution Team works user stories in priority order to completion “done state” using a Plan-Do-Check-Act approach. Sprint Planning During Sprint Planning the team reviews the Product Backlog and estimates and creates the Sprint Backlog. Product Backlog Product features desired by the customer are translated into user stories, placed in the product backlog, and prioritized by the Product Owner.
6. Sprint Cadence Time box to be consistent and align and deliver expected outcomes Day 1 Day 2 Day 3 Day 6 Day 7 Day 8 Day 9 Day 10 Day 13 Day 14 Day 15 Day 16 Day 17 Day 20 Day 21 Wed Thurs Fri Mon Tues Wed Thurs Fri Mon Tues Wed Thurs Fri Mon Tues Daily Standup 15 min X X X X X X X X X X X X X Backlog Refinement X X Sprint Planning 1st day of sprint X Sprint Demo Last day of sprint X Sprint Retrospective Last day of sprint X
7. A Jira Product Backlog Jira, by Atlassian, is one of the most popular software issue-management platforms used today. Stories created in a project are automatically entered into the product backlog. Epics are displayed in backlog view. Clicking into one displays the stories that support the epic’s goals. Once created, you can view them, prioritize, and filter your backlog by them. Reporting is easy in Jira. Sprint reports, Burndown reports, Epic burndowns, and Release burndowns are available to display progress towards goals. Story Point Estimates are displayed down the right-hand side to enable quick grooming and prioritization of work by Product Owners Sprints are created from the backlog and allows users to place work into sprints for prioritization. User Stories are displayed in order of priority. Highest in the backlog equals highest priority. This stack ranking forces prioritization and allows the dev team to pull new work from the top when needed. Components are available to track which stories are associated with specific modules, solutions, or product capabilities to ease reporting.
8. 7 Path to a Release backlog Discovery & Delivery: Start with Spikes, Refine UX/UI & craft Prototypes for certain backlog items Release Backlog Prioritized, Sized/Estimated backlog & potential Sprint 0-1 identified User Story Mapping High level Epics and Features are created by the Product team Refine Backlog Prioritize and Size: Identify Risk, Unknown elements and Infrastructure and Ops activities Product Ideation Key stakeholders discuss and define a product [new or existing]
9. Backlog •Product Backlog: Any desired product feature, you will ever want to build (or NOT) into the product • Do: Add as much detail as possible to the backlog item – despite knowing it needs further research • (Chances are you are not going to get what “fix it” User Story meant in 3 months from now…) • Don’t: Size it or worry about adding the lowest possible detail for it to be ready for development • Owner: SCRUM Team • Product Owner: Continuous Curation Product Backlog Backlog Items
10. Backlog Release Backlog: Prioritized list of Epic-level backlog items w T-shirt Sizes • Do: Release planning meetings (expected outcome: All stakeholder buy-in with prioritized Epics) • Don’t: Size the lowest possible item (User Story) - chances are you are going to keep doing them over & over as you uncover the “unknown” via Sprints (Have T-shirt Sizes for Epics (S, M, L, XL)) • Owner: Release/Product Manager • Stakeholders: Business Lead, Product Engineer, TCoE Lead ,VCoE Lead, Dev Lead (Partner) Product Backlog Release Backlog Backlog Items
11. Backlog Sprint Backlog: Committable amount of User Stories with INVEST criteria • Do: • Do the research needed to acquire all story details • If you don’t have the full details – it is okay to have a Discovery Story - which will help with uncovering the unknown for a potential next Sprint User Story • PO/BA to meet with Delivery Lead, QA, Testing groups prior to Sprint Planning to get buy-in • Atomic User Stories – should be able to wrap-up in a Sprint – if not, break it down • Don’t: • Don’t have TBD in the Stories • Have too much dependency on User Stories • Don’t have a Story in Sprint backlog you can’t complete in Sprint • Owner: SCRUM team • Product Manager: • Work w UX/UI to create Wireframes • Have backlog grooming to discuss discovery stories and delivery stories • Always plan for Infrastructure Stories Product Backlog Release Backlog Backlog Items Sprint Backlog
12. Product Backlog Grooming sessions: Weekly exercise to select to groom the stories: 1. Get the Story ready to be “acceptable into a Sprint” @ Sprint Planning (INVEST) 2. Promote stories from Product backlog to Release backlog or to Sprint backlog 3. Discuss delivery, discovery & Infrastructure stories Backlog - Refinement Backlog Items Estimate/Size Re-prioritize Refine Discard 3 5 3 8 M S S L L XL Underlying Principle: Just Enough Just In-Time
13. Backlog Items Backlog Items Backlog Items Release Planning Sprint Planning Release Backlog: Prioritized Epics with T-shirt Sizes Sprint Backlog: Sized/Estimated, atomic User Stories Backlog Evolution
14. What are you prioritizing for? • Maximize for Business Value • Prioritize Stories which uncover the unknown • Use Pirate Metrics for guidance (AARRR = Acquisition, Activation, Retention, Revenue & Referral)