CSPO Workshop Participant Workbook V5.0 (OCT 2020)
CSPO Workshop Participant Workbook V5.0 (OCT 2020)
CSPO Workshop Participant Workbook V5.0 (OCT 2020)
Trainer
VIJAY BANDARU
CERTIFIED SCRUM PRODUCT OWNER (CSPO) WORKSHOP
AGENDA
DAY 1 TOPICS DAY 2 TOPICS
Forming Teams, Intro & Workshop setup Product Discovery
Product and Product Levels Agile Product planning
Product Lifecycle Product Vision
Minimum Viable Product Prioritization Techniques
Project & Product Mindset Product Roadmap
Agile Manifesto Values & Principles Product Backlog
Scrum Framework overview Product Backlog Refinement
Scrum Framework Elements User stories
Scrum Values and Roles Release planning and Tracking
Scrum Framework Flow Product increment
Sprint, Scrum Artifacts & Definition of Done Release Planning and Tracking Simulation
Product Owner Role Deep Dive Certification Discussion
Day 1 Wrap up Closure
➢ Active knowledge sharing through Linked in Group “Universal Agile & Scrum Community
of Practice”
(https://www.linkedin.com/groups/8305379/)
I hope you enjoy the learning in my class and wish you good luck !!
What is Product?
The Product contains the features that are not available yet POTENTIAL
but may be expected by users in the future
Activity: Go to the blank flipchart nearby your table as a team, chose a product from your
experience as a team and identify all the levels of that product using the below format and
for every level identify the features using post it notes. (10 Minutes)
Have a Gallery walk in clock wise direction to see other table’s work (Spend about 1
Minute at every table)
Product Lifecycle
A minimum viable product (MVP) is a concept from Lean Startup that stresses the impact of
learning in new product development. Eric Ries, defined an MVP as that version of a new product
which allows a team to collect the maximum amount of validated learning about customers
with the least effort.
A key premise behind the idea of MVP is that you produce an actual product (which may be no
more than a landing page, or a service with an appearance of automation, but which is fully
manual behind the scenes) that you can offer to customers and observe their actual behavior
with the product or service. Seeing what people actually do with respect to a product is much
more reliable than asking people what they would do.
Examples:
PROJECT Vs PRODUCT
Activity: Understand Project Vs Product
Below are the characteristics of Product and Project. Discuss at your Table and separate them into
the below table. (3 Minutes)
PROJECT PRODUCT
Activity: Map the below items to the PROJECT and PRODUCT Mindset
What is Agility?
Why Agile?
While there is value in the items on the Right side, we value the items on the LEFT MORE!
12 Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer’s competitive advantage
3. Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale
4. Business people and developers must work together daily throughout the project
5. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely
9. Continuous attention to technical excellence and good design enhances agility
10. Simplicity--the art of maximizing the amount of work not done – is essential
11. The best architectures, requirements, and designs emerge from self-organizing teams
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly
Activity: Understand the below 4 parameters. The RED lines indicate the
behavior of these parameters in waterfall way of working. GREEN lines
indicate the Agile way of working.
(2 Minutes)
➢ Empiricism asserts that knowledge comes from experience and the decisions are
made based on what is known
Scrum Team
Sprint
Sprint Cancellation
Abnormal termination of the Sprint before Timebox expires is called “Sprint Cancellation”
- Only Product Ower can take call on the Sprint Cancellation
- Only reason for Sprint Cancellation is “When Sprint Goal is obsolete”
- When Product Owner decides to cancel a Sprint, below things happen:
o Review of the items (if there are any by that time of canellation)
o Retrospective
o Next Sprint Planning
Definition of Done
✓ Quality criteria checklist
✓ Helps Product Owner and Development team have a shared understanding on “Done”
✓ Created by Scrum team collaboratively
✓ Different for different products
✓ Created before Sprint planning
✓ If there are any organization level quality standards exist, they must be part of DoD
✓ Helps Development team in Sprint planning to forecast the work
✓ In multi-team environment, all teams should have a common Definition of Done
✓ Sprint retrospective is a formal opportunity for Scrum team to inspect and adapt
Scrum Artifacts
➢ Maximize the business value and the work of the Development team
➢ Owns the Product VISION (represents WHY we build product and WHAT the
desired end state is)
W__
W___
Identify Product Owner activities with the INTERNAL (Team) and EXTEERNAL (Beyond Team):
(5 Min)
INTERNAL EXTERNAL
Activity: Read and understand the various shades (anti-patters) of Product Owner role in
various organizations.
Source: https://www.learnovative.com/different-shades-of-the-product-owner-role-in-organizations/
Product Discovery
Do you know the Top 10 reasons for start-ups to fail?
Source: https://www.strategyzer.com/blog/posts/2018/10/15/why-companies-work-on-products-nobody-wants
User:
Customer:
User Research for a new Product is different from User Research for an existing product. For
a new product (0 → 1 Stage), User Research is done to validate product ideas and hypotheses.
For an existing product (1 → n Stage), User Research is done to get feedback on features of
the product.
User Feedback: You can ask users to give their opinions on the
product — their likes and dislikes, and if they would recommend
the product to others
If you want to understand what users say or think, surveys, interviews and focus groups can
help you gauge their beliefs and attitudes. If, on the other hand, you want to focus on what
users do or how they use your product, methods like A/B testing and heatmaps are more
suitable.
Interviews are suitable for gathering qualitative data, whereas surveys are handier for
collecting quantitative data.
Select most appropriate User Research Technique for the below examples
Example scenario description Suitable User
Research Method
Your users are scattered across different locations and you do not have time
to meet everyone in person. But you need to understand their needs.
Your product is already into market and your users are using it. You want to
identify which features have issues with usability or performance issues based
on the information your received from your customer support team.
You have a new feature in your Product which has a complex navigation and
it is also longer. So how do you get inputs from users before implementing
the feature to make sure the navigation is correct?
You are planning your next major release planning. For that you would like to
get critical information from the users who are already using the current
version of your Product. How do you collect the feedback in this scenario?
One of the critical stakeholders has a language problem hence she cannot
explain you the requirement of the Product you are building. However she is
very critical stakeholder so how do you empathize with this Stakeholder?
You are a Product Owner for one of your company’s internal Product and
almost all your company employees will use this new Product. All your
employees are collocated so what is the best approach to collect the inputs?
Persona
✓ Fictional character who interacts with the Product/Service/Result
✓ Useful in considering the goals, desires, concerns
✓ Helps to identify the features based on different Personas
✓ Helps in:
o Coming up with better user experience
o Prevent some common design pitfalls
o Avoid “self-referential” designs
✓ Persona is key in building products that are close to customers’ needs
Use Persona Canvas suggested by Roman Pichler. Explore this approach to get more
information.
The Value Proposition Canvas can be used when there is need to refine an existing product
or service offering or where a new offering is being developed from scratch.
The Value Proposition Canvas is formed around two building blocks – customer profile and a
company’s value proposition.
Customer Profile
• Customer jobs – the functional, social and emotional tasks customers are trying to perform,
problems they are trying to solve and needs they wish to satisfy.
• Gains – the benefits which the customer expects and needs, what would delight customers
and the things which may increase likelihood of adopting a value proposition.
• Pains – the negative experiences, emotions and risks that the customer experiences in the
process of getting the job done.
A customer profile should be created for each customer segment, as each segment has
distinct gains, pains and jobs.
Value Map
• Products and services – the products and services which create gain and relieve pain, and
which underpin the creation of value for the customer.
• Gain creators – how the product or service creates customer gains and how it offers added
value to the customer.
• Pain relievers – a description of exactly how the product or service alleviates customer
pains.
Identifying the value proposition on paper is only the first stage. It is then necessary to
validate what is important to customers and get their feedback on the value proposition.
These insights can then be used to go back and continually refine the proposition.
From the above planning levels, discuss and fill the following:
Planning Part of Scrum? How to represent? Who creates Review
Level Frequency
No Elevator Statement Product Owner Yearly once
Vision Vision Poster (Either creates
Press Release or co-creates)
One Pager
No Roadmap contains 2 to 3 Product Owner Twice an year
Roadmap Releases
Product Vision
Product Vision helps you to “BEGIN with the END in the mind”
Product Vision indicates two factors.
______________ the Product is being Built and
Nike: Bring inspiration and innovation to every athlete* in the world. *If you
have a body, you are an athlete.
• Vision provides ___________ and helps the organization prepare for the future.
• Vision can help to __________ what you will and what you will not do.
Elevator Statement
Be sure to adorn the Poster with the key slogans, images, text and colors that would entice
your customers to “buy” this product.
Keep the following questions in mind when you create your Product Vision Box:
Activity: Create your Product Vision using above two approaches (15 Minutes)
Prioritization
BUSINESS VALUE is the key to Prioritize the Product Backlog. Business Value can be related
to different aspects as listed below:
Prioritization Techniques
DOT Voting
MoSCoW
MUST:
SHOULD:
COULD:
WON’T:
Few more methods to prioritize based on Business Value of Product Backlog Items:
- Value Poker (Relative weight by taking a reference value size and compare the rest)
- Break-even analysis (Cost of feature and expected revenue of the feature)
- Return on Investment ([Profit/Total estimated cost] * 100)
Activity: Create Epic/Feature map for your Product using the below template.
Create the map using post it notes. Using one of the above Prioritization
techniques, prioritize them.
Epic: A big chunk of functionality which takes beyond releases (months) (Eg: User
Management)
Feature: A coherent piece of Epic which is done in a release but beyond sprints (weeks)
(Eg: Register a new user using different ways)
User Story: A small portion of Feature which has some business value and can be done
within a Sprint (days) (Eg: A mobile user can register using his mobile number, A Facebook
user can register using his/her facebook id)
Note: Scrum does not recognize the above naming conventions. In Scrum terminology all
these items are called as “Product Backlog Items (PBIs)”
Product Roadmap
Example Roadmap
Product backlog
Product Backlog is like an iceberg,
you can see only the tip,
not the entire content !
Product Backlog recap: Fill the blanks in the below story to make it complete and
meaningful.
Scrum Master facilitates the Product Backlog Refinement based on the need
User Stories
User Story: As a Visa credit card user, I should be able to pay for the items in the shopping
cart using his/her card so that I can complete my shopping seamlessly
Acceptance criteria:
1. User credit card should be a Visa card
2. All other cards like Master, Amex cards payment should not be accepted
a. Message to show “Only Visa cards are allowed”
3. User card should have valid number of digits
4. Card CVV must be valid and 3 digits length
a. If invalid CVV then: “Wrong CVV, please try again”
5. Cards with expired should be rejected
a. Message: “Your card has expired, please try with another card”
6. Card holder name must be validated
a. Message: “Invalid card, please provide correct card holder name”
7. Different purchase amounts should work with positive amounts
8. Zero or negative amounts should be alerted
a. Message: “Amount should not be negative number”
I_________________ –
N________________ –
V________________ –
E________________ –
S________________ –
T________________ –
Splitting Techniques:
- Work flow steps pattern
- Operations pattern (CRUD)
- Simple to complex pattern
- Data entry patterns
- User Role/Persona based pattern
- Mock UI pattern
- Defer performance pattern
- Breakout a Spike pattern
Story mapping
A very high-level plan for multiple sprints (E.g. 4 – 6 Sprints) is done during release planning.
It is a guideline that reflects expectations about which features will be implemented and when
they are completed. It also serves as base to monitor progress with the project.
Releases can be intermediate deliverables done during the project or the final delivery at
the end.
Prerequisites to create a Release Plan:
➢ A prioritized and estimated Product Backlog
➢ Conditions of satisfaction (goals for the schedule, scope, resources, cost etc.)
Depending on the type of project (Feature driven or Date driven) the release plan can be
created in different ways:
STEP 1:
The first step in fixed-scope release planning is to groom the product backlog to include at
least the product backlog items (PBIs) the organization must have in this release by creating,
estimating the size of, and prioritizing the PBIs that comprise the Minimally Releasable
Features.
STEP 2:
The second step in fixed-scope release planning is to determine the total size of the PBIs to
be delivered during the release. Do this by summing up the estimates of the must-have PBIs.
STEP 3:
The third step in fixed-scope release planning is to measure or estimate the team’s velocity
as a range.
STEP 4:
The fourth step in fixed-scope release planning is to divide the total size of the PBIs for the
release by the fastest velocity in the range. Round the answer up to the next integer. This will
indicate the lowest number of sprints required to deliver the features targeted for the release.
STEP 5:
The fifth step in fixed-scope release planning is to divide the total size of the PBIs for the
release by the slowest velocity in the range. Round the answer up to the next integer. This
will indicate the greatest probable number of sprints required to deliver the features targeted
for the release.
EXAMPLE
When asked how many sprints it will take to deliver the fixed scope, you can now answer
using a range: somewhere between the greatest probable number of sprints and the least
number of sprints. Suppose, for example, your features targeted for a release is estimated to
be 150 points, and the Scrum team’s predicted velocity range is 18-22 points per sprint. You
can estimate that the MRF will be delivered in 7-9 sprints. If you are running 2-week sprints,
this would equate to 14-18 weeks.
STEP 1:
The first step in fixed-date release planning is to determine how many sprints are in the
release. If all sprint lengths are equal (which should be the ideal case), this is simple calendar
math, because you know when the first sprint will start and you know the delivery date.
STEP 2:
The second step in fixed-date release planning is to groom the product backlog to a sufficient
depth by creating, estimating the size of, and prioritizing product backlog items. You’ll need
enough PBIs to plan out to the fixed release date.
STEP 3:
The third step in in fixed-date release planning is to measure or estimate the
team’s velocity as a range.
STEP 4:
The fourth step in fixed-date release planning is to create a “will have” line by multiplying the
slowest number in the velocity range by the number of sprints. Count down that number of
points into the product backlog and draw a line.
STEP 5:
The fifth step in fixed-date release planning is to create the “might have” line by multiplying
the largest number in the velocity range by the number of sprints. Count down that number
of points into the product backlog and draw another line.
STEP 6:
The final step in fixed-date release planning is to compare the “will have” and “might
have” lines to the minimum releasable features (MRFs) in the product backlog. If all of the
must-have items are above the will have line, you are in great shape. If not, you will need to
decide whether to proceed as planned, revisit the MRFs, pivot, or terminate the project.
The image below shows several variations in how the must-have features (MRFs) might
compare to the will have and might have calculations from fixed-date release planning.
After the Release Planning is done, the Scrum team starts Sprinting
to create potentially releasable product increment. Product Owner
closely collaborates with the Development team and the
Stakeholders to make effective decisions based on collaborative
discussions with them.
During each Sprint, the Development team tracks the progress of the work of Sprint using
some tracking mechanism. Most common approach is a “Sprint Burndown”.
Below are some example Burndown chars of a team which has different scenarios:
The Development Team updates the Sprint Burndown chart. Ideally it should be
updated as and when a user story is “Done”, or else at least once in a day it should
be updated.
Blue line (Top) indicates the overall release backlog size. Till the 5th Sprint, it is same but in
Sprint 6 it has increased, that means some new work is added. Red line (bottom) indicates
the cumulative completion of the work in every Sprint. So, at the 8th Sprint, “Remaining work
to be complete” can be found by subtracting red line value (work complete) from the blue
line value (Total work). So, in the above it is 120 minus 97 which is 23. Now, to understand
how many more sprints it is needed to complete the 23 points of work, you have to check the
average velocity of all 8 Sprints. In the above it is: 12.125, let’s take 12. So now divide the 23
(remaining work) with 12 (Velocity) which gives the number of Sprints required to complete.
23/12 = 2 (rounded). This is how the Product owner will track the overall release progress.
VIJAY BANDARU WWW.LEARNOVATIVE.COM 69
CERTIFIED SCRUM PRODUCT OWNER (CSPO) WORKSHOP
Velocity
Product increment
APPENDIX
www.pdfdrive.net is a great
online PDF books repository.
There are plenty of online books
available in there, so please try to
search for the books and read
them.
Google Drive Link:
https://tinyurl.com/CSPO-Vijay-Bandaru