What Is The Product Development Lifecycle by former Symantec PM
•Download as PPTX, PDF•
2 likes•267 views
This talk was an introduction to scrum and the product development lifecycle. Scrum is a framework of agile, the most prominent software development methodology today. Shelli went over the scrum process, its main elements and team roles as well as the 5 levels of planning that are part of the product release process.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to What Is The Product Development Lifecycle by former Symantec PM
Similar to What Is The Product Development Lifecycle by former Symantec PM (20)
More from Product School
More from Product School (20)
Recently uploaded
Recently uploaded (20)
What Is The Product Development Lifecycle by former Symantec PM
- 1. What Is the Product Development Lifecycle by former Symantec PM www.productschool.com
- 2. FREE INVITE Join 23,000+ Product Managers on
- 3. COURSES Product Management Learn the skills you need to land a product manager job
- 4. COURSES Coding for Managers Build a website and gain the technical knowledge to lead software engineers
- 5. COURSES Data Analytics for Managers Learn the skills to understand web analytics, SQL and machine learning concepts
- 6. COURSES Blockchain and Cryptocurrencies Learn how to trade cryptocurrencies and build products using the blockchain
- 8. Introduction to the Product Development Lifecycle Through Agile and Scrum
- 9. Ana Sheila Victorino Instagram @shellsla Linkedin: /anavictorino/ ● Product Manager at Symantec for Norton Wifi Privacy product ● Stanford BA in International Relations, UCLA MBA ● Co-founder of a Public Service program for high school girls ● Fitness/physical challenge fanatic ● Sports lover & Jeep owner ● ESL kid
- 10. Agenda 1. What is Agile Methodology? 2. Introduction to the Scrum framework and ceremonies 3. Product Visioning and exercise 4. Product Roadmap and exercise 5. Writing stories and exercise
- 11. What is Agile Agile software development is a set of principles based on iterative development, where requirements and solutions evolve through collaboration between self- organizing cross-functional teams.
- 12. Agile Manifesto Individuals and Interactions Working Software Customer Collaboration Responding to Change Process and Tools Comprehensive Documentation Contract Negotiation Following a Plan AGILE!
- 13. What is Scrum Scrum is a process framework with a particular set of practices and ceremonies that provides a specific way to develop software following Agile principles .
- 14. The Scrum Team Product Owner ● Owner of product vision - the what, where, and why ● Feature (epic and story) definition and refining Scrum Master ● Process Mentor ● Coach/Facilitator ● Clears roadblocks ● Manages velocity and progress Scrum Team Member ● Self Organizing development team ● Decide what to work on ● Work closely with PM, provide input on stories, write all tasks for stories
- 15. The Scrum Ceremonies 1a. Backlog Refinement 1. Sprint Planning 1. Daily Standup 1. Sprint Review 1. Team Retrospective
- 16. 5 levels of planning 1. Vision 2. High level roadmap 3. Release Plan 4. Sprint Plan 5. Daily Commitment Vision Release 1 Release 2 Release 3 Sprint 1 Sprint 2 Story 1 Story 2 Daily Commitment!
- 17. Visioning What does your product do? What are your goals for your product this year? Is everyone aligned?
- 18. Visioning Statement For (target customer) Who (statement of the need/opportunity) The (product name) is a (product category) That (key benefit, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation)
- 19. Visioning - Exercise ● Break into groups ● Think of an existing company or an idea for a company and write your vision ● Note that there will be follow up exercises with whatever you choose ● Share :)
- 20. Roadmap and Requirements gathering ● Communicates the whole ● Determines when releases are needed ● Determines what capabilities are sufficient ● Focuses on business value derived from the releases ● See the whole ● Learns about the steps ● Learns the business priorities ● Provides technical and feasibility input to the roadmap “A product road map is a planning artifact that shows how the product is likely to evolve across product versions, facilitating a dialogue between team and stakeholders”. Product Owner role Team member/developer
- 21. Roadmap & Requirements Gathering ● Quarter ● Theme/Goal/Focus ● High Level features ○ Can be categorized ● Metrics
- 22. Roadmap examples
- 23. Roadmap - Exercise ● Break into your groups ● Focus on just the next quarter ● Draft a roadmap for just the upcoming quarter with your group in whatever format you want - could have a theme or goal, be split up by type of functionality ● Write three big features and or functionality that you estimate could be completed in one quarter
- 24. Stories A user story is a tool used in Agile to capture a description of a software feature from an end-user perspective. The user story describes the WHO (the type of user), the WHAT (what the end user wants) and the WHY (why they want it). A user story helps to create a simplified description of a requirement.
- 25. Stories Questions to ask yourself about your stories ● Do they have a user, a need, and an estimable business value? ● Is the user an end user? ● Can the story be completed in one sprint?
- 27. Acceptance Criteria ● Conditions that the story meets in order for it to be considered done ● Boundaries for features at a high level ● Contain actor, behavior, result ● Generally provided by the Product Owner/Manager ● Assist the team in understanding story, creating tests ● Help the team know when to stop adding functionality ● Implementation-independent ● Acceptance Tests ● SMART ● Specific – concrete, unambiguous ● Measureable ● Achievable ● Relevant – connected to the story ● Time-bound – know when to expect outcome
- 28. Story Examples
- 29. Stories - Exercise ● Break into your groups ● Write two stories about your product based on one of the things you have in your roadmap for the first quarter ● Include acceptance criteria for the stories ● Remember that each story should be something that can be completed in a two week sprint
- 30. Thank you! Shelli.victorino@gmail.com IG: @shellsla Linkedin: /anavictorino
- 31. Part-time Product Management Courses in San Francisco, Silicon Valley, Los Angeles, New York, Austin, Boston, Seattle, Chicago, Denver, London, Toronto www.productschool.com
Editor's Notes
- understand web analytics, learn SQL, and machine learning concepts
- First to start of with the most exciting part of this presentation. When I talk about me! Just kidding hopefully, this will be the least interesting part as youll be so excited about everything youre going to learn!
- OLD manifesto valued doing it “right” the first time anc centralized controlled. Less team and customer involvement in a very rigid process. Learn as you go Incremental progress Empowered teams Leverage workers knowledge
- A product manager is the person responsible for defining the why, when, and what of the product that the engineering team builds. They lead cross-functional teams from a product's conception all the way through to its launch
- Daily Scrum - Every day Update /Daily commitment Call out blockers or questions Sprint Planning Every 2-4 weeks Demo Discussion Sprint Retrospective – Every 2-4 weeks Review and evaluate process - Every 2-4 weeks PO/PM presents priority backlog items (based on stakeholder and customer feedback) Team defines sprint goal Team decides what they can deliver in a sprint Team adds tasks to the stories Product Backlog refinement Sizing Prioritizing Clarifying Sprint Review –
- Product Management with Scrum relies on multiple levels of planning:
- Revisit your vision at least once a year if not more depending on how mature your product is.
- After your vision comes your roadmap. Read quote The key point is “likely to evolve” The roadmap provides a high level meat to the vision and goals for the product usually with a year view and broken up into quarters The roadmap must have high level buy in from key stakeholders and all team members. It also needs to be shared when any stakeholders that might have interest in the roadmap of the product for visibility The PM is responsible for putting together the roadmap after discussions with key business stakeholders, own analysis of product data and feedback, and input from architects and engineers They loosely allocate when releases should come based on impact and business value
- There are different templates you can use for your roadmap. You just have to determine what works best for you audience. Usually you will see the roadmap for the year broken up by quarters One thing to remember always is that were in an agile environment and this roadmap should be flexible. You need to remind yourself but more importantly you have to remind your business stakeholders that. Sometimes business stakeholders will expect to see something delivered in quarter 3 because they saw it in Q3. In an agile environment you have to be willing to assess your roadmap and move things up, add something new if there is a business case, or if data now presents a more important initiative. It’s also important to review the roadmap and share it out regularly. At least quarterly but more often if there are large changes you think you need to make. The first quarter should be pretty close to accurate in terms of what you hope to deliver BUT some things might end up delivering in the following quarter. The further along in your roadmap, the less concrete timelines and features and functionality will be. From ther you could organize your roadmap by giving the quarter a goal or focus. Everything that comes after that should support that goal. You list the high level features and functionality that fill those goals in that quarter You can further break down these initiatives by type of work that it is
- Here is just a little snippet of an old roadmap of mine. I don’t think I can really share so it’s just to show you how I organized it. I had goals for the quarter First quarter it was just really focusing on improving the actual performance of of our VPN - faster connectivity, less disruption, etc. It was a relatively new product that we had also recently moved from mobile only to cross platform so we wanted to make sure the product worked well and that there was a seamless transition from standalone app to a full fledged Norton product The second quarter, we wanted to build partner capabilities that did not exist, make some small quick UX wins that we hadn’t had a chance to make. Lastly we wanted to review and strengthen our telemetry. I can tell you that this was too ambitious and we weren’t able to complete all we wanted in the quarter. Quarter 3 I actually didn’t have a quarter 4 for this roadmap. I just had a parking lot of different things we were considering. You can call it Q4 and beyond or do a section like this. Again, it depends on your product. You might have a pretty clear view of what you think you will be doing in Q4. I then split each quarter into different sections Product enhancements Backend Offering expansions Marketing initiatives Telemetry I included a screenshot of a sample roadmap template as well. Another good thing to do that I like from this one is to include the expected release that the feature will go in. That also gives stakeholders some good visibility all in the roadmap so they know what to expect in upcoming releases. You still need to shareout the components of what’s in a release when you have locked it down. Note that the initial roadmap you do would not have the release numbers in it because you don’t plan a release until you have the larger features (epics) defined for your quarter, defined the high level requirements and then created stories and as a team decided which release it is in (note whether I have already explained that or not)