Product Owner Certification + 2 Mock Tests
- 2 hours on-demand video
- 2 Practice Tests
- Full lifetime access
- Access on mobile and TV
- Certificate of Completion
Get your team access to 4,000+ top Udemy courses anytime, anywhere.Try Udemy for Business
- Become a Product Owner in a Scrum teams
- You will become Scrum Certified
- Make delivery estimations in agile
- Execute on a product vision
- Run experiments to validate the value of the items in your backlog
- Pass professional product owner PSPO and CSPO certification test
- You should have a basic understanding of agile terminology and concepts
- You should know that this course is difficult
- You should know to take time to practice the material instead of rushing through the course.
- You should know that this course qualifies for Scrum Alliance Education Units (SEUs) under Category E (Independent Learning)
To be effective, Product Owners need to have a firm grasp on the value drivers for their product, and a keen sense of how to use agile practices and Scrum to maximize that value. The Professional Scrum Product Owner (PSPO) assessments allow people to validate and certify their understanding of the role of the Product Owner and how they would respond to real situations that would challenge them.
NEW: After receiving lots of messages from my students on my Scrum Master Certification Course, I have added a new lecture in this course about how to manage product backlog in an effective way. This course will save you hundreds of pounds on Scrum training and help you to pass Scrum Product Owner certification in your first try.
What will you learn?
This Course enables aspiring Product Owners to develop their knowledge of how to maintain and manage a responsive product backlog, and have a product vision that represents the stakeholder’s and customer’s requirements. At the end of this course you will not only learn about the product owner role within scrum framework but also will have detailed knowledge on scrum to direct your team using the best practices of agile and scrum.
New Addition: I have added a lecture to this course about INVEST technique.
Why this course?
Because I have trained hundreds of Product Owners and got consistent feedback. My course content is created out of real life scenarios and experiences.
In my course you will also learn everything included in Scrum Guide which is primary source of passing Professional Product Owner Certification.
You will be able to ask me questions via Udemy messaging system
Disclaimer: This course has professional voice over as well as a professional teacher in front of you virtually - face to face.
Who this course is for:
This course is for Scrum Team Members, Scrum Masters, Scrum Product Owners.
This course is for product managers who will transition to agile environments or product managers who will start their journey as a newbie.
Business analysts, testers, software developers can also step into their product owner role journey with this course.
Anyone who is planning to Pass Product Owner Certification tests
- Beginner Product Owners for Scrum Team
- Candidates Appearing for Product Owner Certification Exams
I am a Certified Scrum Master and Agile Coach.
For over 11 years I've been building high-performing software development teams
through the use of Agile and Scrum.
I have worked as Product Owner for some widely known applications you might be using on daily bases. I have worked with some of the most difficult Product Owners and Stakeholders from Industry leading Engineering companies.
I have gathered all of my experience in this course for you. So that you can learn from real life situations.
You will not just learn about Scrum Values, Roles, Events, Artifacts etc. But you will deep dive into how you can make sure to retain high value delivery cycle for your product. Why Return on Investment is so crucial for stakeholder, how evidence based management works.
My in-person training, coaching, and online video courses work together to give you everything you need to deliver the right product to the market.
Not only that you will be able to attend Professional Product Owner Certification Exam with full confidence and get it cleared.
I have a 98.6% Passing rate of my students.
Enrol yourself today and achieve your new career goals.
Every high-functioning Agile team that you see has a well-trained Product Owner making critical product decisions.
Product Owners ensure on-time delivery of high-value releases and maximise the ROI.
A globally recognised Professional Scrum Product Owner™ Certifications , therefore, is a career-defining credential for anybody willing to take up challenging roles in agile coaching or higher positions in an organisation.
The industry today is ripe with endless opportunities for Product Owners. With 90% of modern teams using Scrum, the demand for Certified Scrum Product Owners (CSPO) has seen a steep rise.
The Product Owner may represent multiple customers’ requirements but has the responsibility and authority to reconcile conflicting requirements and determine the business value.
Scrum Alliance has done a survey and found out that
38% of the participants had a Product Owner working in this capacity.
15% indicate that the Product Owner works directly with the team, when their role should be to motivate the teams with a clear business goal—not be directly involved with the work. Furthermore,
22% indicate no Product Owner role. This may become problematic and indicates that more education and awareness of this role is needed.
Here are 7 steps you need to take in order to get your Professional Product Owner Certification
Read the Scrum Guide and get really familiar with it. This is the primary source of all answers for the assessment
Review the Scrum glossary for quick definitions of key terms
Complete My Course
Do the Scrum Open assessment until you can do it fast and score close to 100% 3 times in a row.
Do the Scrum Product Owner Open assessment until you can do it fast and score close to 100% 3 times in a row.
Finish two mock tests in my course. This offers different questions to the Scrum.org Open assessments so is an additional opportunity to test your knowledge in advance of sitting the real assessment.
Contact me with your questions. I like it when you do!
When you are ready to take the assessment for real:
Go to Scrum.org. Select PSPO 1 certification. Register with Fee $200
Use the link in the email you will have received from Scrum.org
Have the Scrum guide and the Scrum glossary to hand and use it to look up what you need
Don’t spend too long on each question. If unsure of an answer, note down the question number and move on. Completing all the questions in the time box can be challenging.
Come back to the hard questions at the end and use your time to think them over.
Google the question if really unsure, but be careful as this takes time and there are lots of unreliable sources out there.
If time permits, check all your answers before the end.
Product Owner Characteristics
There are five common characteristics for product owners:
##1. Available and Engaged
A key aspect of the role is being available to answer questions from the development team. Questions can arise at any time and any delay will impact the capability of the team. The most successful projects have fully engaged product owners working daily as an integral part of the team.
The organisation must empower the product owner to make decisions with the knowledge that they will be held accountable. In order to maintain the required speed of development, decision-making must be made locally at the product level. If the product owner is frequently overruled by the organisation hierarchy, then their team will start to bypass them when asking questions.
The development team's questions must be answered promptly and with authority. Delaying decisions will prevent the work planned from being completed, and frequently reversing previous decisions will lead to a lack of trust. There is a balance to be made, but with the knowledge of the customer and support of internal stakeholders the product owner is in the best position to make these decisions.
##4. Good Domain Knowledge
The product owner must have a good understanding of the target customers needs and appropriate business knowledge to lead development in coordination with all of the stakeholders. This requires strong support networks within the organisation and the creation of good relationships with customers and third-party suppliers.
##5. Great Communication
This role requires an excellent communicator, collaborator and “people person” capable of sharing a vision, aligning people, focusing efforts and motivating the team. High emotional intelligence will help to collaborate and steer the product development to a successful conclusion.
Scrum clearly puts the “value” as number one focus for the Scrum Team.
However, it neither defines what is deemed as value nor explains how to measure it. The authors of Software-in-30-days book define that
“Value is the measure of how valuable the delivered functionality is to the organisation. It is a measure of the effectiveness (a percentage) of each dollar spent on software development that creates value for the organisation”
In other words, value involves getting more Return on Investment (ROI) at less Total Cost of Ownership (TCO). Return on Investment is not just about revenue. It could mean different things to different organisations.
The ROI represents the benefits gained from the investment versus the costs that was expended.
For each decision that managers make, they should be considering the ROI, and collaborating with the customer to ensure that everyone agrees upon options that maximize the ROI. Any backlog item should add value to the project. While it clearly costs to implement a new process for a team, the benefits are more difficult to calculate.
To choose the approach that is correct for the project, you must determine a method to effectively compare the different approaches and to establish which will gain a better ROI.
However, an issue exists in comparing development methods. Numerous studies used pseudo-science and estimation to evaluate each method.
Their conclusions are based on how the method fits into Agile principles or how the companies feel that the method is working out for them.
In one study, project managers were asked to compare their experience with popular processes, and a conclusion was based on the popular choice. This is bad science. In other studies, metrics have been developed to estimate the costs of these methods and perceived benefits.
For example, one study calculated costs and benefits by the lines of code that were produced. However, there is no any guarantee that a greater number of produced lines increased the effectiveness of the team, and the same method may not work for your company or your project.
The field of software development process evaluation needs to be advanced in a more empirical and studious manner.
While a methodology may work for one company, one size does not fit all.
You should start your development process by evaluating different methods and assessing the gains for your own business. The first step in comparing methods is to establish a scenario where two or more processes can be evaluated through the same guidelines.
This can be achieved in two ways. The first approach entails comparing two projects that are similar in size, scope and cost, then developing each project using a different process. However, this approach does not guarantee success, as two projects are never exactly the same.
It can also be difficult to transition a team from a traditional methodology to an Agile methodology.
A better option is to take a large project and break each process into a small, medium and large piece, allowing you to compare the processes together.
You should perform the testing processes against the traditional methodologies, and then transition the team into the Scrum methodology by performing the same processes in an agile way.
While this approach has some of the same pitfalls as the two projects approach, the risks will be mitigated by the number of pieces and by the transitory approach. The “piece approach” could take a couple of iterations, as your team needs to get used to the Scrum process.
After the test scenario is set up, we need to measure hard values that can be used to calculate a ROI. One such measurement is the time required establishing a stable build. While this definition may be different per company or project, a good measurement of a stable build is one that contains no critical bugs. By taking this measurement and calculating the man-hours used, we can have a hard value of which method costs less. Another method is the number of critical bugs found, as they require considerable resources to correct. By correcting the bug in both methods, you can measure the resources used in both methods and compare the expense of both. By measuring these values, you can compare any savings to the amount of money invested, thus calculating your ROI.
TCO includes not just the Product development costs, but also the cost of maintenance, and operations of the product throughout its life.
The authors of the book Software-in-30-days classify the cost as capital cost and expenses.
Development costs are separated because they can be capitalised. Maintenance and operations costs are expensed.
From the Developer standpoint, aspects such as simplicity (no unnecessary code for example), support documentation, automated test beds, conformance to design and development standards, minimal external dependencies, etc. are typically perceived as means to increase the technical quality.
A product with high technical quality reduces the cost of maintenance, and operations of the product throughout its life, leading to lower TCO for the organisation.
So, in addition to prioritising the investment on building highly usable features, Product Owner can have the Development Team optimize the value further by developing a high technical quality product.
Product Owner maximise value by prioritisation and ordering Product Backlog Items
Product Owner prioritises the requirements(product backlog items) and adds all other requirements into the product backlog. She uses different types of prioritisation techniques like MoSCoW, value proposition, business value or Kano Model to prioritise backlog. Maximise the business value by continuous prioritisation and ordering of product backlog items are the core skills of a good Product Owner. Product Owner does this to ensure most valuable work get completed as early as possible. Based on prioritisation, product owner prepares product roadmap for short-term and long-term. Product roadmap usually includes detailed work items for 2 – 3 sprints and high level features, visions for longer durations.
Product Owner collaborate with Development Team to maximise value
Product owner presents the product backlog items to the development team through backlog refinement and sprint planning meetings. She clarifies the requirement to the team and answer their queries. Product Owner and Development team defines the acceptance criteria for refined work and they do it together. The product owner manages the releasees by taking care of the scope and ensures development team is aware about changing scope by making product backlog transparent. It is the duty of the product owner to bring the best from the team to achieve the business value. A good product owner gives authority to the team to express their views, accepts their inputs and suggestions related to the product and do not force the team to complete more product backlog items. He lets the team to make a commitment for the user stories based on their capacity for the sprint.
What is MoSCow technique?
The MoSCoW method is a prioritisation technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement; it is also known as MoSCoW prioritisation or MoSCoW analysis. MoSCow Prioritisation Technique plays a key role in Agile Project Management. In an Agile project it is vital to understand the importance of different things. This is because time is a fixed resource, so prioritisation is applied to requirements, tasks, products, user cases, etc. Be very careful, this is not Agile technique (include Scrum, Kanban, XP and so on) however this technique is widely used in Agile. There are some questions in almost all certifications regarding MoSCoW technique.
Prioritisation of MoSCoW requirements
All requirements are important, but they are prioritised to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver all the Must have, Should have and Could have requirements but the Should and Could-requirements will be the first to be removed if the delivery timescale looks threatened.
These provide the Minimum Usable Subset (MUS) of requirements which the project guarantees to deliver. This may be defined using some of the following:
Cannot deliver on target date without this
No point in delivering on target date without this; if it were not delivered, there would be no point deploying the solution on the intended date
Not legal without it
Unsafe without it
Cannot deliver the Business Case without it
Ask the question, “what happens if this requirement is not met?” If the answer is “cancel the project – there is no point in implementing a solution that does not meet this requirement” then it is a Must Have requirement. If there is some way round it, even if it is a manual workaround, then it will be a Should Have or a Could Have requirement. Downgrading a requirement to a Should Have or Could Have does not mean it won’t be delivered, simply that delivery is not guaranteed.
Important but not vital
May be painful to leave out, but the solution is still viable
May need some kind of workaround, e.g. management of expectations, some inefficiency, an existing solution, paperwork, etc.
A Should Have may be differentiated from a Could Have by reviewing the degree of pain caused by it not being met, in terms of business value or numbers of people affected.
Wanted or desirable but less important
Less impact if left out (compared with a Should Have)
Won’t Have this time
These are requirements which the project team has agreed it will not deliver. They are recorded in the Prioritised Requirements List where they help clarify the scope of the project and to avoid being reintroduced ‘via the back door’ at a later date. This helps to manage expectations that some requirements will simply not make it into the delivered solution, at least not this time around.
MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) is primarily used to prioritise requirements, although the technique is also useful in many other areas. I recommends no more than 60% effort for Must Haves for a project, with 40% Should's and Coulds. Anything higher than 60% poses a risk to the success and predictability of the project, unless the environment is well understood, the team is established and the external risks are minimal.
Traditionally, projects tend to measure success in terms of meeting a pre-defined plan. That is, if the project achieves a pre-defined scope of work at acceptable quality, within the pre-defined cost and time, it is deemed as the success. Unfortunately, these measures do not necessarily represent elements of value. Though projects may deliver on time, the outcome might be obsolete, the user adoption might be poor, technical quality might make the product very rigid to enhance, etc.
Scrum.org has provided a framework to measure the value of software. It is called as Evidence Based Management or EbMgt. EBMgt measure three Key Value Areas (KVA) to measure the value of software:
Time to Market
Ability to Innovate
Eleven Key Value Measures are defined under these three KVA.
1. Revenue Per Employee measures - Gross Revenue /number of employees
2. Product Cost Ratio measures - All expenses in the organisation that develops, sustains, provides services, markets, sells, and administers the product or system.
3. Employee Satisfaction measures - Engaged employees that know how to maintain, sustain and enhance the software systems and products are one of the most significant assets of an organisation.
4. Customer Satisfaction measures - Sound management, solid software, and creative, fulfilled employees
Time to Market:
5. Release Frequency measures - The time needed to satisfy the customer with new, competitive products
6. Release Stabilisation measures - The impact of poor development practices and underlying design and code base. Stabilisation is a drag on competition that grows with time
7. Cycle Time measures - The time (including stabilisation) to satisfy a key set of customers or to respond to a market opportunity competitively
Ability to Innovate:
8. Installed Version Index - The difficulty customers face installing a new release. The relatively low value of new releases, or even the number of customers that are evaluating alternatives.
9. Usage Index - Determines a product that is burdensome and difficult to use and excess software that must be sustained even though it is rarely used.
10. Innovation Rate measures - Growth of technical debt caused by poorly designed and developed software. Budget is progressively consumed keeping the old software alive
11. Defects measures - increasingly poor quality software, leading to greater resource and budget to maintain it and potential loss of customers.
Each of these metrics is measured continuously. The continuous array of data provides insight into the trends and patterns. An organisation can make changes in the processes, behaviour, tooling, etc. and trace their impact on improving these metrics. All these can be consolidated into an overall Agility Index for the organisation. Agility Index is an indication of how effective the organisation is in delivering value.
Another method for measuring the success and value of the product is recommended by Roman Pichler. It is known as Product Scorecard that has four elements to measure: Financial, Customer, Product & Process, and People.
You as Product Owner can see that there is no hard and fast rule about how to measure the value and success of the product. In fact, a Product Owner chooses the measures that make sense for their context, and then inspects their effectiveness and adapts.
However, there are few things that a Product Owner needs to avoid:
Avoid the vanity metrics. Vanity metrics are those that seem to provide some surface level quantification but don't necessarily add value
Avoid measuring too many aspects. Limit to handful of metrics that are closer and effective reflections of product value and success
Release planning is longer-term planning that enables us to answer questions like “When will we be done?” or “Which features can I get by the end of the year?” or “How much will this cost?” Release planning must balance customer value and overall quality against the constraints of scope, schedule, and budget.
Every organisation must determine the proper cadence for releasing features to its customers.
Though the output of a sprint is potentially shippable, many organisations choose not to release new features after every sprint. Instead, they combine the results of multiple sprints into one release.
Other organisations match the release cadence to the sprint cadence. In such cases the organisation releases the potentially shippable product increment created during that sprint at the end of each sprint.
Some organisations don’t even wait for the sprint to end; they release each feature as it is completed, a practice often referred to as continuous deployment (or continuous delivery). Such organisations release a feature or a change to a feature to some or all of their customers as soon as the feature is available, which might be as often as several times a day.
Whether the organisation intends to deploy every sprint, every few sprints, or continuously, most organisations find some amount of longer-term, higher-level planning to be useful. I refer to this type of planning as release planning. If the term release planning seems inappropriate to your context, replace the term with one that is better suited. Synonyms I have heard different organisations use include:
• Longer-term planning
• Milestone-driven planning
The inputs to release planning include outputs from product planning, such as the product vision, high-level product backlog, and product roadmap. We also need the velocity of the team or teams that will work on the release. For an existing team, we use the team’s known velocity; otherwise, we forecast the team’s velocity during release planning.
One activity that recurs in release planning is to confirm the release constraints of scope, date, and budget and to review them to see if any changes should be made, given the passage of time and what we now know about the product and this release.
Another activity of release planning is product backlog grooming, which includes creating, estimating, and prioritizing more detailed product backlog items from high-level product backlog items. These activities could occur at multiple points in time:
• After product planning but before initial release planning
• As part of the initial release-planning activity
• During each sprint as necessary.
Each release should have a well-defined set of minimum releasable features (MRFs). Even so, during release planning we always review the MRFs to ensure that they truly do represent the minimum viable product from the customers’ perspective.
The outputs of release planning are collectively referred to as the release plan. The release plan communicates, to the level of accuracy that is reasonable given where we are in the development effort, when we will finish, what features we will get, and what the cost will be. This plan also communicates a clear understanding of the desired minimum releasable features for the release. Finally, it frequently will show how some of the product backlog items map to sprints within the release.
The word commitment usually relates to undertaken duties. After committing to deliver a list of Product Backlog Items, the Scrum Team, foremost the Product Owner and especially the stakeholders may feel that there is an obligation to actually deliver all of them at the end of the Sprint. But reality keeps on showing us that it is difficult, if not impossible, to always fulfil this self-imposed commitment without making compromises to quality. A Sprint Backlog is complex enough that uncertainty is always present, and common sense tells us that we shouldn’t promise what we are not sure to be able to deliver. When we use the word commit, we can be easily biased towards that duty-obligation-promise way of thinking.On the other hand, the chosen alternative “forecast” has to do with making assumptions based on reliable information and evidence. This is much closer to how an experienced Scrum Team works, where everybody knows that the initially crafted Sprint Backlog - and thus, the associated list of Product Backlog Items - is subject to change as more becomes known throughout the Sprint. The Scrum Team also knows that reaching the end of the Sprint without having done all the initially selected Product Backlog Items sometimes just happens, despite its best efforts. Continuous collaboration between the Development Team and the Product Owner thus leads to renegotiation of the scope of the Sprint Backlog during the Sprint; if we pay attention to the meaning of the words, this would lead us to have a broken commitment versus a non materialised forecast. When a commitment is broken or not fulfilled, it is usual to expect some sort of accountability, fault, or even compensation. When a forecast doesn’t come true, it is easier to think about matters such as learning from the experience, improvement and - in one word - empiricism, which at the end is what Scrum is about.
But the most important reason for the change (which is a direct consequence of the former argument), is the misuse, and even abuse, that the word commitment has suffered during lots of so called “Scrum” projects. Typically the situation arises from one –or both- of the following sources: the “business” side of the project (customer, stakeholders or even the Product Owner), or the Development Team itself.
It is not uncommon (or unreasonable, frankly) for people on the business side to hear that the Development Team has committed to deliver a list of Product Backlog Items and take it literally. They expect to have every single item delivered at the end of the Sprint, at any price. And, what is even worse, they begin making plans, assumptions and decisions based on this not yet confirmed fact. Then, if the commitment is not fulfilled, they may try to “claim their guarantee”, and ask for liable individuals. This is especially frequent when the business has not yet gotten rid of their former command-and-control, non-agile project management mindset.If we have a look at the Development Team, many times the situation is not better. The team takes the commitment as a venture aimed at delivering every single bit of functionality which was promised at the beginning of the Sprint - once again, at any price. The only indicator for success is reaching the X-axis in the Sprint Burndown, the sooner the better, and sometimes even at the expense of software quality or the real business value being delivered.
I frequently find Development Teams, whether inexperienced or with a pretty broad Scrum background, putting the fulfilment of the entire commitment above anything else. They take it as a replacement for the real goal (which we are going to refer to in a moment). If they fail the commitment, they will express - maybe at the Retrospective – their disappointment with themselves, or try to find someone to blame inside the Team, instead of taking the opportunity to inspect, learn and adapt to improve for subsequent Sprints.Either way, whether the commitment concept is abused by the business people or by the developers themselves, the usual victim is product quality, as Ken Schwaber himself has repeatedly pointed out.
The Development Team is pushed under the wrong kind of pressure, and the team members find themselves struggling to deliver each and every one of the selected Product Backlog Items by means of rushing, taking shortcuts, accumulating technical debt and not fulfilling the Definition of Done.
As a logical consequence, the Development often starts to pad its estimates to avoid the permanent pressure vise. Hopefully, getting rid of the word commitment in favour of forecast will help Scrum Teams avoid these pitfalls, and focus on what really matters.
At a first glance, one evident drawback could be the difficulty in getting used to the new term. We could find it difficult to begin adopting “forecast” for upcoming conversations and writings, or to remember the reasons for the change when reading “commitment” all over the already written material. Well, I think that in fact it’s not that hard to get into the habit, and the potential benefits are well worth the effort.Besides that, there may be another (apparent) obstacle. At first sight we may think - maybe some people are mistakenly already doing so - that changing commitment by forecast will drive Development Teams to believe that they can happily relax, and assume that they can finish any Sprint without delivering a usable increment of software. Since it’s only a forecast…it’s not our fault if we don’t manage to get any single item done, right?Well…actually “commitment” remains there. As you can see for yourself, the Scrum Guide only refers to forecast when dealing with the list of Product Backlog Items selected for a Sprint. But for any hardly competent person working as a developer, commitment is still present in Scrum and, furthermore, in software development itself, at all levels:At a personal level, developers worth that title will commit to be professionals, striving always to do their best at work, given the available environment and resources. Dan Pink describes this fact in his book ‘Drive’.At the values level, any Agile developer will of course commit to value people, working software, collaboration, and responding to change. He will surely commit even further than that, and go for technical excellence, continuous learning and improvement, team building and the whole set of Agile principles.And what about Scrum? Is still any commitment there? You’d better bet for it. At the Scrum framework level, developers:
Commit to fulfill the Sprint Goal, which if well-crafted, tells the Development Team members why they are building the Increment. Unlike the list of selected Product Backlog Items for the Sprint, the Sprint Goal is coarse enough to allow the Development Team to navigate and satisfy the commitment. This avoids anyone blindly expecting that any single selected item will be delivered under any circumstance.
Commit to assure that they deliver a usable increment at the end of the Sprint, which includes only items that are fully finished according to the Definition of Done that has been agreed to beforehand.
Commit to continuously inspect and adapt, to better support the empiricism that lies at the heart of Scrum.
And at the end, commit to the values and elements that build up the framework, which allow us to tell that we are doing Scrum instead of anything else.
In Scrum, the Development Team is now asked to forecast the specific work that can be done in a Sprint, rather than “commit” to it. This allows teams to focus on the things that matter in professional software development like quality, value, and continuous improvement, rather than satisfying an arbitrary obligation.Business-facing people (Product Owner, stakeholders, customer…) must recognize the inherent uncertainty in building software of any real value and complexity. Their responsibility is to create an environment where Development Teams can succeed, and trust in those teams’ professionalism to do all they can to deliver things of value.
Have you ever worked on a Scrum project where the overall goal was not clear?
Where you had a product backlog but the people involved in the development effort only vaguely understood the purpose of the release?
It happens more frequently than any of us would like, even on projects with multi-million pound budgets!
Often Scrum’s emphasis on “getting work done” is misunderstood as a rush to develop with not enough thought to where the project should be going. Don’t make that mistake.
Every Scrum project needs a product vision that acts as the project’s true north, sets the direction and guides the Scrum team. It is the overarching goal everyone must share – Product Owner, ScrumMaster, team, management, customers and other stakeholders.
As Ken Schwaber puts it: “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.”
“Vision is the art of seeing things invisible,” The product vision paints a picture of the future that draws people in.
It describes who the customers are, what customers need, and how these needs will be met. It captures the essence of the product – the critical information we must know to develop and launch a winning product.
Developing an effective product vision entails carefully answering the following questions:
Who is going to buy the product?
Who is the target customer?
Which customer needs will the product address?
Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product?
How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points?
What is the target timeframe and budget to develop and launch the product?
Answering these five questions also gives us the information to create a business case. It allows us to decide if and how the project should proceed.
Creating the Product Vision
Since the Product Owner is responsible for the success of the product and its return on investment (ROI), he or she should lead the vision-creation activities through close collaboration with the team (Pichler 2008).
At the heart of the product vision is the description of the selected customer needs and the necessary product attributes meeting those needs. To arrive at this vision, we first select our target customers and then the relevant customer needs, thereby deciding which market or market segment we are going to address.
Then we identify the product attributes, those critical high-level requirements the product must fulfil to satisfy the needs.
Product attributes typically comprise both nonfunctional and functional requirements.
The product vision must be clear and easy to understand to create alignment and a common purpose, and to avoid misinterpretation and confusion
An effective product vision guides the Scrum team and aligns stakeholders and customers. Spending time and money on vision creation is a worthwhile investment.
Too many new-product projects move from idea stage right into development with little or no up-front homework.
Solid pre-development homework drives up new-product success rates significantly and is strongly related to financial performance.
This does not mean procrastinating the start of development, using an upstream waterfall process that creates a mighty product concept or employing a separate project. The trick is to spend as little time as possible but as much as required; to use Scrum to create the vision; and to ensure that as many of the team members involved in the vision creation as possible also transform it into the actual product.
The goal of Product Backlog refinement is to work with the Scrum Team and stakeholders (when relevant), to get Product Backlog items in a ‘ready state’. What does this mean? This basically means that the development team has the idea that an item is:
Clear enough, so they understand what stakeholders are asking for and why they are asking for it.
Small enough, so the items should be small enough to get done within a sprint (typically a few days of work) to comply with the definition of done.
The most important part of Product Backlog refinement actually is before you start refining. The most ineffective use of a Scrum Team's time would be to refine an item that doesn’t contribute to the product vision. For a Product Owner, one of the first steps when a stakeholder has an idea is to find out what this person would like to have and why they need it. A common pitfall is that a stakeholder asks for a solution, the 'how', and a Product Owner in all it’s enthusiasm fails to retrieve what they would like to have and why they need it. Numerous times I have seen stakeholders ask for an iPad app. This sounds incredibly valuable and any developer would like to spend time on this over working on some legacy application. However, when the reasons behind the solution are unclear it will most likely end up somewhere hidden in the app store.
Typically a Product Backlog item goes through three refinement meetings before it is considered to be in a ready state. First, when a stakeholder comes with an idea or wish, the team would roughly estimate the size of the item. A very fast way to do this is by 't-shirt sizing'. Nobody knows the exact size of a small sized t-shirt but everybody has an idea about the relative difference in size between a small and medium sized shirt. It is the first input for a Product Owner to get an idea on the effort involved in realising the item.
The second part is to assign story points to the item but again in a quick and dirty way. The format often used is Magic estimation or Silent estimation. This is estimating effort without having long and in depth discussions on the item.
The final stage before an item is considered to be ready by a Development Team is to do planning poker. This is a frequently used technique for estimating items. This technique is time consuming so preferably you would only apply this for items you actually want to be realised and based on previous estimation you have considered to be valuable enough to spend the effort.
Ward Cunningham was the first to write about the concept of technical debt
If I understood if correctly he defines it as:
Shipping first time code is like going into debt. A little debt speeds development so as long as it is paid back promptly with a rewrite its fine.
The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organisations can be brought to a stand-still under the debt load of an unconsolidated implementation.
Cunningham used the technical debt metaphor to explain to his business team why creating software fast to get feedback was a good thing. In doing so, however, he emphasised two key points:
The team and organisation need to be vigilant about repayment of the debt as their understanding of the business domain improves, and the design and implementation of the system need to evolve to better embrace that understanding.
Since the introduction of the term in the early 1990s, the software industry has taken some liberties with Cunningham’s definition.
Nowadays, technical debt refers both to the shortcuts we purposely take and also to the many bad things that are dangerous for software systems.
• Unfit design
• Insufficient test coverage
• Excessive manual testing
• Poor integration and release management
• Lack of platform experience
• And many more, because the term technical debt today is really used as a placeholder for a multidimensional problem
Consequences of Technical Debt:
As the level of technical debt rises, so does the severity of the consequences. Let’s discuss a few of the more notable consequences of high levels of technical debt
Increased Time to Delivery:
Taking on technical debt means taking a loan today against the time required to do future work. The greater the debt today, the slower the velocity tomorrow. When velocity slows, it takes longer to deliver new features and product fixes to customers. So, in the presence of high technical debt, the time between deliverables actually increases rather than decreases. In ever-competitive marketplaces, technical debt is actively working against our best interests.
For a product with high levels of technical debt, making any sort of prediction is nearly impossible. For example, estimates become bad estimates even for the most experienced team members. There is simply too much uncertainty surrounding how long something might take when dealing with a debt-ridden product. Consequently, our ability to make commitments and have a reasonable expectation of meeting them is seriously impaired. The business stops trusting anything development has to say, and customers stop trusting anything the business has to say!
Decreased Customer Satisfaction:
Customer satisfaction will decrease as customer frustration increases. So the extent of the damage caused by technical debt is not just isolated to the development team or even to the development organisation as a whole. Even worse, the consequences of technical debt can substantially affect our customers and their perception of us.
Making Technical Debt Visible:
One of the principal benefits of the technical debt metaphor is that it enables the development team and the business people to have a necessary conversation using a shared context. It is also essential to provide business people with visibility into the product’s technical debt position.
Congratulation on finishing your Product Owner Certification Course. Please take both mock tests.
Make sure you complete them 2 to 3 times until you have full confidence and get more than 95% in each.
I wish you good luck with your Scrum Certification exam.
Welcome to your Mock Exam Test. Please note that the test has both multiple choice style questions with radio buttons and multiple response questions with tick boxes. A multiple response question will have 1 or more answers.
Remember: There is no explanation in this mock as I want you to treat it as a real exam