8. PRODUCT MANAGER EVALUATES PRODUCTS
1. What is this product trying to do? (BUSINESS)
2. How well do it do it? (TECHNOLOGY)
3. Does this design of the product facilitate or
hinder this? (DESIGN/UX)
20. UNDERSTAND USER FLOW
‣ Capture sequence of activities
‣ Helps you plan out what to sketch or
wireframe next
‣ Focus on “screens” or major views in
your web or mobile app
‣ Lines represent transitions due to user
action
25. CREATE PRODUCT ROADMAP CYCLE
‣ Gather feedback from stakeholders, clients and
customers
‣ Prioritise and rank based on importance, client and
revenue impact
‣ Begin to implement strategic roadmap initiatives and
developing features
‣ Measure the success of each initiative
‣ Constant evaluation to ensure working on most
important features, reprioritise if necessary
29. AGILE MANIFESTO
“That is, while there is value in the
items on the right, we value the
items on the left more.”
www.agilemanifesto.org
30. SCRUM IN LESS THAN 100 WORDS
➔ Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest
time
➔ It allows us to rapidly and repeatedly inspect actual
working software (every one week to one month)
➔ The business sets the priorities. Teams self-organize
to determine the best way to deliver the highest
priority features
➔ Every one week to a month anyone can see real
working software and decide to release it as is or
continue to enhance it for another sprint
“.. a faster, more reliable,
more effective way
to create software in
the tech industry.”
– Jeff Sutherland
32. ● Pigs: Participants - Product Owner, Scrum Master & Engineers
○ Product Owner: Voice of the customer, an individual who owns product
backlog, adjudicates and sets goals for a sprint
○ Engineers: 3-8. Choose/build Stories to address the goals, develop the
software code
○ Scrum Master: Servant-leader. Applies the rules of Scrum, facilitates
meetings, enforces code of conduct and time limits, addresses team
blockers
● Chickens: Observers - Managers and customers
○ Managers: Provide resources, help remove blockers
○ Customers: Confirm when goals are ‘Done’
SCRUM TEAM: PIGS
AND CHICKENS
33. DESCRIBE REQUIREMENT WITH USER STORY
Epics - A user story that will take more than 2-3 sprints to develop and test.
User Stories - A specific function that has value to the customer.
Tasks - Specific granular parts of a user story that are worked on during a sprint
(2-8 hours duration)
“As a ……. I want to ……. so that I can …….”
Epic
Epic
Epic
User story
User story
User story
User story
Task
Product Backlog Sprint Backlog
Task
Task
Task
Task
Task
Task
User story
34. PRODUCT BACKLOG
➔Created, prioritized and
maintained by Product Owner
➔Ordered list of all (known)
desired work on the project
➔Ideally expressed such that each
item has value to users/
customers of the product
➔May be incomplete and evolves
as more project requirements
becomes known
Backlog item Estimate
As a user, I want to see all available services so
I can choose which service to order
As a user, I want to see the information of each
service so I can understand what I will be
getting with my order
As the architect, I want to see how the order
is processed by the service engine so I know
the system is running fine
As an analyst, I want to see the report of all
services ordered for period of time so I can
get insight what service most users want
...
36. Every sprint has a goal to specify the focus of work and what to deliver at the end
Team choose user stories from Product Backlog to be included in Sprint Backlog
Ideally there should be no change to what being work on during one Sprint cycle
SPRINT TIME BOX
Sprint
2-4 weeks
Sprint Planning
2-4 hours
Sprint Review
1-2 hours
Retrospective
0.5-1 hour
Sprint Time Box
Daily Scrum
15 minutes
37. SPRINT PLANNING
➔Team selects items from the
product backlog they can
commit to completing
➔Sprint backlog is created
➔Tasks are identified and each is
estimated (1-16 hours)
➔Collaboratively done by the
team, not alone by the Scrum
Master or Product Owner
➔High-level design is considered
Sprint planning meeting
Sprint prioritization
• Analyze and evaluate
product backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint
goal (design)
• Create sprint backlog (tasks)
from product backlog items
(user stories / features)
• Estimate sprint backlog in
hours
Sprint
goal
Sprint
backlog
Business
constraint
Team
capacity
Product
backlog
Technology
Current
product
38. KANBAN AS VISUAL TOOL
Visual display of current state
Focus on tasks worked on in the present
Limits number of items being worked on at once
Progress items through states e.g.:
● Backlog
● Assigned
● Current/Working
● Testing
● Done
Work from right-to-left ‘pull’ work towards completion
E.g. if ‘Current’ or ‘Doing’ queue is empty, it can pull the tasks from ‘To Do’ queue
39. SPRINT DAILY
➔Daily, 15-minutes max, Stand-up
➔Not for problem solving
➔Whole world is invited but only team
members, Scrum Master, Product Owner,
can talk
➔Helps avoid other unnecessary meetings
➔Everyone answers 3 questions
➔These are not status for the
ScrumMaster, they are commitments in
front of peers
What did you do yesterday?
1
What will you do today?
2
Is anything in your way?
3
40. SPRINT REVIEW AND RETROSPECTIVE
Sprint Review: Team presents what they have
accomplished during the sprint. Typically
takes the form of a demo of new features or
underlying architecture. Informal, no
slides.
Sprint Retrospective: At the end of Sprint,
take a look at what is and is not working.
Whole team gathers and discusses what
they’d like to:
Start doing
Stop doing
Continue doing
41. BURN-DOWN/UP CHART
Simple graph showing amount of work on
a vertical and timeline on a horizontal
axis
Burn-down: to keep track how much
work is still not done
Burn-up: to keep track how much work
we have completed
Can show when the scope changes