Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Agile Product Development Process

No description

Yves Sy

on 22 February 2018

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Agile Product Development Process

Breaking down ideas or epics into user stories
Agile Product Development Process
Figuring out what to build
Building the roadmap
Release planning
Prioritizing the backlog
Product Vision
Identify need
Identify market
Business Value
Key features
Competitive edge
Success criteria
Design the Box
Press release & FAQ
Moore format
For (target customer)
The (product name) is a (product category)
That (key benefit, compelling reason to buy)
Unlike (primary competitive alternative)
Our product (statement of primary differentiation)
Product Vision Board
Product Pitch
Establish User Personas
Picture and Name
Primary Persona
Gather ideas
Quarterly Feature Workshops
Includes all stakeholders - Sr. Management, PMs, Design, Product Team, Marketing/PR, ECS, etc.
User feedback
Internal Suggestions
Capture everything in one place!
Issue type: Idea in JIRA
Usually a whole day activity
Needs to have a fun atmosphere
Plenty of storyboards, post-its, markers, etc.
Fosters collective ownership of product
Social Media
Make it easy to send in suggestions, e.g. contest+ideas@
Should be reviewed regularly by the Product Owner
Non-functional Requirements (NFR)
Impacts User Experience
Influences architecture and design
Can be described as constraints in user stories
Can also be standalone user stories
Key Activities:
Define your Product Vision
Product pitch
Quarterly feature workshops
Product Vision Statement (Moore format) or Product Vision Board
User Personas document
Non-functional Requirements
Backlog of Ideas in JIRA
"For local freelancers and employers, Local Jobs is a crowdsourcing platform that allows local employers to crowdsource tasks for specific skills. Unlike Airtasker, our focus will be to allow entrepreneurs to build apps that focus on mobilizing freelancers with specialized skills through an API. "
Determine business value of ideas
Form your team
Market testing
Competitor analysis
UI prototypes
Usability studies & testing
Key metrics
MoSCoW ideas/epics
Should - important for project success but can wait a bit
Could - nice-to-haves
Musts - critical to project success, and need to be delivered immediately
Wont - lowest value items, must be revisited later on or dropped altogether
Ideas, once validated, can be turned into Epics
Epics are essentially large user stories or high-level specs
Epics can span several sprints or even projects
Should contain:
As a... I want... so that...
Story boards
As an employer, I want to be able to outsource jobs locally so that I can free up more personal time.
Architectural Analysis
Conduct spikes to reduce risks and prove technical viability
How does it fit into existing systems?
How will the product evolve? e.g. do we need to support mobile?
Output: Architectural Document
Answers Non Functional Requirements
Uses Views & Perspectives to address technical concerns
The Roadmap
Get the MVP out ASAP!
Product Backlog
Tech task
Next 2-3 sprints, very detailed, "ready" state
4-6 sprints away, some detail, incomplete stories
2 months+ away, high-level specs
Monthly Roadmap Review
Don't be afraid of change -- welcome change!
Involve all stakeholders to foster buy in and collective ownership (Sr. Mgt, Product Team, Marketing/PR/Comms)
Key Activities:
Determine business value of ideas
MoSCoW ideas and epics
Monthly roadmap review
Architectural Document
Product Backlog
High-level Architectural Analysis
Sprint Zero
User Stories
Basic unit of executable features
Need to be small enough to be able to fit in a sprint
Format: As a <persona>, I want <feature> so that <benefit>
Acceptance criteria
Success metrics
As a freelancer, I want to be able to log on to the site so that I can bid on projects
Acceptance criteria:
Log in box should pop up as modal
Freelancer cannot have more than one concurrent session
3 max attempts before being locked out
Log in should be over SSL
Log in should be less than 100ms
A few more notes about user stories...
As a developer/PM... is NOT a user story!!
Make sure you schedule a weekly review of the most critical stories with your stakeholders.
Stories must be in a "ready" state - feasible, testable, clear - before the team works on it
All stories in your backlog need to be estimated
Top of the backlog must contain "ready" stories
Goal: Maximize ROI with the least amount of effort
Project target release dates based on velocity
Use best case and worst case projections
Assign stories to future sprints based on estimates
Roadmapping is at the strategic level, while Release Planning is at the tactical level
Aim to get your MVP out ASAP
Publish your Release Plan in Confluence
Update your Release Plan after every sprint
All stakeholders and the product team should be present
Product Team
Also includes:
Key Activities:
Break down epics into stories
Review critical stories with stakeholders
Estimate all stories in the backlog
User Stories
Release Plan
"Ready" stories on top of backlog
Release Planning
A technical task whose aim is to increase knowledge and reduce risk
Can be a research activity, experiment, proof-of-concept, prototype, etc.
Gets the team prepared for upcoming sprints
1 2 3 4 5 6 7 8
Pink = average velocity
Blue = best case scenario based on variance
Orange = worst case scenario based on variance
Give feedback early and often
Close stories ASAP in sprints in sequential order
Spin up dev environments for PMs as needed
Try to keep your sprint scope frozen as much as possible
Get feedback early and often
Weekly demos (or screencast) to stakeholders
Regular usability and/or hallway testing
Track and analyze metrics
Update the Release Plan every sprint and communicate back to stakeholders
Key Activities:
Updated Release Plan
Close stories in sprints ASAP
Weekly demos to stakeholders
Usability and hallway testing
Track your metrics
Update your release plan after every sprint
Final Thoughts & Next Steps
PMs should champion and follow through, but it has to be a collective and conscious effort from everyone
Different product teams have different strengths and gaps at the moment
You can get away with skipping bits and pieces now and then but it will eventually come back to bite you
Not a magic pill but aims to provide a solid foundation for how we develop products moving forward
Use the Issue Collector in JIRA
Release Planning
For more info on how to do Release Plans in JIRA: http://bit.ly/1Em4ar4
Release Plan
Sprint 1:
User Story 1
User Story 2
Sprint 2:
User Story 3
User Story 4
Release version 1.0 (June 10-17)
Sprint 3:
User Story 5
User Story 6
Sprint 4:
User Story 7
User Story 8
Release version 2.0 (July 23-30)
Upvote/downvote ideas in a forum
Full transcript