Category

Courses

Search

Trending blog posts

CSPO Filter

How to Become a Certified Scrum Product Owner?

Who is a Certified Scrum Product Owner (CSPO® )?A Product Owner is a role defined in Scrum. Scrum is a framework for complex product development (*). The Product Owner is responsible for maximizing the value of the product resulting from the work performed the Development Team. The role exists in Scrum to have 1 person with a clear accountability of WHAT product or service will be built. The Product Owner role is also used as a title outside Scrum, in other frameworks, but if you want to understand the definition of the role and responsibilities of a Product Owner, you need to start to look and to understand it in the scope of a Scrum Team.  (*) (“product”, to be defined in context, this is a generic term for the product or service being developed for the end-users) (*) (“development”, also to be defined in context, this is a generic term for all activities needed to create and deliver value to the end-users)A Certified Scrum Product Owner is a certification issued by the Scrum Alliance for the Product Owner role.Roles and Responsibilities of the Certified Scrum Product Owner :A Product Owner is responsible for maximizing the value of the product (or service, …) being built. The Product Owner is responsible for WHAT will be built by the development teamThe role of the Product Owner can be quite challenging and high-demanding.When reading The Scrum Guide, it says that product backlog management is the main activity for a Product Owner. The product backlog is a tool to ensure it’s clear what’s needed in the product and what’s the most valuable thing to build next. Managing a backlog, and refining items on the product backlog is a continuous activity. The Product Owner often serves as the spokesperson for the product. This means he/she needs to be able to answers questions appropriately, for example regarding product vision, roadmap, planning, why certain choices have been made, etc. This also includes NOT answering certain questions, because the Product Owner knows the development team is in a more appropriate position to answer the question more accurately, and as well to facilitate a conversation with the development team involved. The strategic significance of the CSPO®The Product Owner role in Scrum is a role, both with a tactical, strategic and operational aspect. The Product Owner is the personification of the end-users, customers, business stakeholders. He or she represents the different views, perspectives and he or she is finally accountable for maximizing value.To be able to do the job, the Product Owner has business (domain) knowledge, affinity with end-users, affinity with “development” (activities needed to deliver a piece of value), and knowledge of how to do agile product management. Product management is a multi-disciplinary job.Sometimes, a Product Owner is a role given to a person, as an additional role to his/her existing function. To my experience, a Product Owner requires at least half the time of a normal day job. I have seen Product Owners who were not involved in the necessary activities. Given below are the duties crucial to any Product Owner.Do’sTreat requirements as a hypothesis, focus on learningEnsuring Product Backlog items are clearly expressedKeep slicing for value (use techniques as user story mapping)Create a shared understanding by visualizationChallenge the team by asking open questionsChallenge your stakeholders by repeatedly asking “Why?”Engaging with end-users to get feedback, treat the sprint review at the last responsible moment to get feedbackFacilitating Product Backlog Refinement (necessary to ensure items are ready to be planned in an upcoming sprint)Treat estimates as estimates, not commitments, trust the teamFeed the team with problems not only solutionsFocus on goals (long-term and short-term)Communicate uncertainty to stakeholders, as uncertaintyUnderstanding Lean Product DevelopmentDo engage in retrospectivesBe fair about what’s done and not doneSet an example, act and speak according to Scrum Values and Agile PrinciplesTips to consider for becoming CSPO® What is CSPO®  certification?CSPO®  stands for Certified Scrum Product Owner. It’s the initial (entry-level) certification of a Product Owner. Scrum Alliance is the accredited body of the CSPO® . Now, let’s see the steps for becoming CSPO® . Prerequisites to become a CSPO® There are no specific prerequisites to attend a course. You can attend a live online or in-person course taught by a Certified Scrum Trainer® (CST®), or receive private coaching from a Certified Agile Coach (CAC). After successfully completing the course, you will be asked to accept the CSPO License Agreement and complete your Scrum Alliance membership profile.Who can take up this CSPO®  course?Anyone interested in the Product Owner can take up this course.Why you should become a CSPO®  certified?A CSPO®  certification is accreditation and a proof of a body of knowledge at a specific point in time. The industry is asking for certifications, so if you want to take up the Product Owner role, a certification can give you this extra accreditation.Difference between CSPO®  and PSPO CSPO®  is an abbreviation which stands for Certified Scrum Product Owner. This is a certification offered by the Scrum Alliance, specifically for the Product Owner role. PSPO is an abbreviation which stands for Profession Scrum Product Owner. This is a certification offered by scrum.org, specifically for the Product Owner role.In my opinion, both certifications are equivalent and define a high-quality standard. Certifications issued by scrum.org do not expire. Of course, to test and validate your knowledge, having a decent understanding of the product owner role is mandatory, therefore preparation and study are key. Participating in training to learn, and to experience what Scrum is about, is always highly recommended. You can study the PSPO Subject Areas.Importance of the CSPO®  certification for an individual to boost his/her career as a successful Product OwnerYou need to decide for yourself if you think certifications are an added value. Eventually, it’s about a hands-on experience in the role. I do think that classroom course offers an added valueIn case you want to take up the role of a Product Owner, and you have not much knowledge yet, a classroom course is recommendedIn case you already are working as Product Owner, and you want to refresh your knowledge, take an updated perspective, a classroom course is recommendedCSPO®  certification validityCertification gives you access to a renewable, two-year membership with Scrum Alliance. The certification is 2 years valid. You can read here how it works to renew your certification.Step-by-step process to become a CSPO®  1. Find a Certified Scrum Product Owner course on the Scrum Alliance website2. Prepare for the trainingRead and understand the Scrum GuideRead and understand the manifesto for agile software development3. Attend the 2-day course. Enjoy!Salary and career growth of Certified Scrum Product Owner vs Non-certified Scrum Product OwnerHere, you can see an overview of the certifications path offered by the Scrum Alliance and Scrum.org. According to the 12th state of the Agile report by VersionOne, the chapter is about “Agile Methods and Practices”, having a dedicated customer or product owner is a technique indicated by 63% of the respondents. In the 2017 State of Scrum report (by Scrum Alliance), 40% of certifications are Certified Scrum Product Owner. 81% agree that certification improves practice.ConclusionBeing a product owner is a satisfying job! If you get a certification it will add an extra line on your curriculum which will catch the eye of recruiters. Besides that, it’s a learning journey and you’ll only understand the traits of the job by experience. Get your CSPO® certification today.Have a successful career ahead!

How to Become a Certified Scrum Product Owner?

7583
How to Become a Certified Scrum Product Owner?

Who is a Certified Scrum Product Owner (CSPO® )?

A Product Owner is a role defined in Scrum. Scrum is a framework for complex product development (*). The Product Owner is responsible for maximizing the value of the product resulting from the work performed the Development Team. The role exists in Scrum to have 1 person with a clear accountability of WHAT product or service will be built. The Product Owner role is also used as a title outside Scrum, in other frameworks, but if you want to understand the definition of the role and responsibilities of a Product Owner, you need to start to look and to understand it in the scope of a Scrum Team. 

 (*) (“product”, to be defined in context, this is a generic term for the product or service being developed for the end-users)

 (*) (“development”, also to be defined in context, this is a generic term for all activities needed to create and deliver value to the end-users)

A Certified Scrum Product Owner is a certification issued by the Scrum Alliance for the Product Owner role.

Roles and Responsibilities of the Certified Scrum Product Owner :

A Product Owner is responsible for maximizing the value of the product (or service, …) being built. The Product Owner is responsible for WHAT will be built by the development team

The role of the Product Owner can be quite challenging and high-demanding.

When reading The Scrum Guide, it says that product backlog management is the main activity for a Product Owner. The product backlog is a tool to ensure it’s clear what’s needed in the product and what’s the most valuable thing to build next. Managing a backlog, and refining items on the product backlog is a continuous activity. 

The Product Owner often serves as the spokesperson for the product. This means he/she needs to be able to answers questions appropriately, for example regarding product vision, roadmap, planning, why certain choices have been made, etc. This also includes NOT answering certain questions, because the Product Owner knows the development team is in a more appropriate position to answer the question more accurately, and as well to facilitate a conversation with the development team involved. 

The strategic significance of the CSPO®

The Product Owner role in Scrum is a role, both with a tactical, strategic and operational aspect. 

The Product Owner is the personification of the end-users, customers, business stakeholders. He or she represents the different views, perspectives and he or she is finally accountable for maximizing value.

To be able to do the job, the Product Owner has business (domain) knowledge, affinity with end-users, affinity with “development” (activities needed to deliver a piece of value), and knowledge of how to do agile product management. Product management is a multi-disciplinary job.

Sometimes, a Product Owner is a role given to a person, as an additional role to his/her existing function. To my experience, a Product Owner requires at least half the time of a normal day job. 

I have seen Product Owners who were not involved in the necessary activities. Given below are the duties crucial to any Product Owner.

Do’s

  • Treat requirements as a hypothesis, focus on learning
  • Ensuring Product Backlog items are clearly expressed
  • Keep slicing for value (use techniques as user story mapping)
  • Create a shared understanding by visualization
  • Challenge the team by asking open questions
  • Challenge your stakeholders by repeatedly asking “Why?”
  • Engaging with end-users to get feedback, treat the sprint review at the last responsible moment to get feedback
  • Facilitating Product Backlog Refinement (necessary to ensure items are ready to be planned in an upcoming sprint)
  • Treat estimates as estimates, not commitments, trust the team
  • Feed the team with problems not only solutions
  • Focus on goals (long-term and short-term)
  • Communicate uncertainty to stakeholders, as uncertainty
  • Understanding Lean Product Development
  • Do engage in retrospectives
  • Be fair about what’s done and not done
  • Set an example, act and speak according to Scrum Values and Agile Principles

Step-by-step process to become CSPO

Tips to consider for becoming CSPO® 

  • What is CSPO®  certification?

CSPO®  stands for Certified Scrum Product Owner. It’s the initial (entry-level) certification of a Product Owner. Scrum Alliance is the accredited body of the CSPO® . Now, let’s see the steps for becoming CSPO® . 

  • Prerequisites to become a CSPO® 

There are no specific prerequisites to attend a course. You can attend a live online or in-person course taught by a Certified Scrum Trainer® (CST®), or receive private coaching from a Certified Agile Coach (CAC). After successfully completing the course, you will be asked to accept the CSPO License Agreement and complete your Scrum Alliance membership profile.

  • Who can take up this CSPO®  course?

Anyone interested in the Product Owner can take up this course.

  • Why you should become a CSPO®  certified?

A CSPO®  certification is accreditation and a proof of a body of knowledge at a specific point in time. The industry is asking for certifications, so if you want to take up the Product Owner role, a certification can give you this extra accreditation.

  • Difference between CSPO®  and PSPO 

CSPO®  is an abbreviation which stands for Certified Scrum Product Owner. This is a certification offered by the Scrum Alliance, specifically for the Product Owner role. PSPO is an abbreviation which stands for Profession Scrum Product Owner. This is a certification offered by scrum.org, specifically for the Product Owner role.

In my opinion, both certifications are equivalent and define a high-quality standard. 

Certifications issued by scrum.org do not expire. Of course, to test and validate your knowledge, having a decent understanding of the product owner role is mandatory, therefore preparation and study are key. Participating in training to learn, and to experience what Scrum is about, is always highly recommended. You can study the PSPO Subject Areas.

  • Importance of the CSPO®  certification for an individual to boost his/her career as a successful Product Owner

You need to decide for yourself if you think certifications are an added value. Eventually, it’s about a hands-on experience in the role. I do think that classroom course offers an added value

  • In case you want to take up the role of a Product Owner, and you have not much knowledge yet, a classroom course is recommended
  • In case you already are working as Product Owner, and you want to refresh your knowledge, take an updated perspective, a classroom course is recommended

  • CSPO®  certification validity

Certification gives you access to a renewable, two-year membership with Scrum Alliance. The certification is 2 years valid. You can read here how it works to renew your certification.
Stakeholder Management

Step-by-step process to become a CSPO®  

1. Find a Certified Scrum Product Owner course on the Scrum Alliance website

2. Prepare for the training

Read and understand the Scrum Guide

Read and understand the manifesto for agile software development

3. Attend the 2-day course. Enjoy!

Salary and career growth of Certified Scrum Product Owner vs Non-certified Scrum Product Owner

Here, you can see an overview of the certifications path offered by the Scrum Alliance and Scrum.org. According to the 12th state of the Agile report by VersionOne, the chapter is about “Agile Methods and Practices”, having a dedicated customer or product owner is a technique indicated by 63% of the respondents. 

In the 2017 State of Scrum report (by Scrum Alliance), 40% of certifications are Certified Scrum Product Owner. 81% agree that certification improves practice.

Conclusion

Being a product owner is a satisfying job! If you get a certification it will add an extra line on your curriculum which will catch the eye of recruiters. Besides that, it’s a learning journey and you’ll only understand the traits of the job by experience. Get your CSPO® certification today.

Have a successful career ahead!

Frederik

Frederik Vannieuwenhuyse

Blog Author

Frederik is an experienced consultant, professional facilitator, coach and trainer. Frederik is constantly looking to help organisation to gain more agility and to create happy workplaces

Join the Discussion

Your email address will not be published. Required fields are marked *

1 comments

Maricruz 07 Jan 2019

I have been surfing online more than 2 hours today, yet I never found any interesting article like yours. It’s pretty worth enough for me. In my view, if all site owners and bloggers made good content as you did, the web will be a lot more useful than ever before. Greetings! I've been reading your blog for a long time now and finally got the bravery to go ahead and give you a shout out from Lubbock Texas! Just wanted to tell you keep up the excellent work! It’s the best time to

KnowledgeHut Editor 23 Jan 2019

Thank you so much Maricruz.

Suggested Blogs

Combination Of Agile & DevOps – The Roots

Agile and DevOps are two notions that originate from the same schools of thought, but whose paths now have digressed. However, a major amount of confusion still remains within the IT services industry with regards to the relationship between the two and has emerging agile & devops trends in 2017. Hence, it is of value to look at the origins of each and to clarify the disparities between them. ‘Tell me what you want, what you really really want!!’ Does the tune ring a bell? Back in the 1990s, the Spice Girls were expressing to the world what they really really wanted, and similarly business owners and corporate leaders were doing pretty much the same, indicating what they wanted to software developers who were working on enabling these organizations through technology. Unfortunately, these business owners were not as lucky as the Spice Girls. More often than not they really didn’t get what they wanted. By the time business requirements were properly understood, validated and finally realized through software products the business requirements more or less had changed.  This was mainly due to the ‘application delivery lag time period’ that sometimes went up to three years. The result of the aforementioned delay from concept to realization meant that a large proportion of projects were stopped before completion. Even then, those that eventually reached the finish line more often than not did not meet the end users’ expectations.  The introduction of Agile – The change-driven management approach The search was on for a more lightweight approach to solution delivery and the result was ‘agile’ – a project management approach with a series of new concepts with regards to collaboration between business owners and the implementation team including UI / UX engineers, developers and even QA engineers. Instead of eliciting, documenting and signing off all the requirements up front and getting it signed off before work began, the focus shifted to delivering value through increments of functional software that would evolve over time. The results indicated that the software implementation team had become more productive, businesses could be more responsive in responding to queries of the implementation team, and user demands could be met more efficiently. However, problems remained. The agile approach didn’t always deliver on the promise of continuous, seamless software development. Blockers continued to exist. So, what is DevOps? The first thing to note is the fact that DevOps is not an individual tool or a suite of solutions but more of a philosophy whose primary purpose is to reduce the distance between the worlds of software development and IT operations. It defines how the original concepts of agile have moved downstream to the level of infrastructure and operations. The DevOps concept sounds relatively straightforward, but in reality it is a little bit more complicated. Software development and IT operations have historically had very different approaches. Software developers appreciate the ability to change things quickly and often they do end up changing things rapidly. In the meantime IT operators focus on stability and on minimizing alteration. This philosophical disparity has often resulted in conflicts. Thus, one of the main challenges of DevOps is to ensure that this conflict decreases before it affects the businesses. Importance of DevOps Principles For this very reason indicated above, it is very important to consider and act up on the core principles of DevOps. They are, Close collaboration and communication between developers, system operators and software testers Continuous integration that requires developers and operators to commit to changes more frequently Continuous delivery to increase the team’s speed and efficiency while enabling early detection of bugs Continuous deployment to ensure new developments can be released without system downtime The DevOps philosophy goes hand-in-hand with the delivery processes described in ITIL Framework in terms of support and IT services management. DevOps can therefore be seen as a way to implement ITIL processes in such a manner that meets the demands placed on systems today.  
Combination Of Agile & DevOps – The Roots
Blogs
3326
Combination Of Agile & DevOps – The Roots

Agile and DevOps are two notions that originate fr... Read More

Metrics that matters for DevOps Success

DevOps is generally introduced for the development teams to speed up the software delivery. DevOps is considered as a step beyond Agile. Many enterprises accepted DevOps as a part of software delivery process from planning, developing, deploying and updating an application, according to reviews. In this competitive world, DevOps allows businesses to speed up with the rapid pace of demands by the customers.Here are the top Ways to Obtaining Business Benefits of DevOps. Customers of today demand quality as well as security based products. DevOps, making the best use of its principles, provides superior quality and lowers the risk. On the contrary, in traditional software development approach, increased speed often results in poor quality and increased vulnerabilities. Why are metrics essential? Most organizations implement DevOps because of the demand for quality, time improvement and the need for defect-free products. Since DevOps has no specified framework, there exist a few standard ways to measure DevOps success. How do you find out how well it can work? How will you come to know whether it is working or not? The answer to this question, and the solution to all the existing problems, is the use of Metrics. Metrics are essential to stay in sync with DevOps. DevOps will be used extensively which therefore requires continuous treatment. But if you are not measuring its outcomes, you cannot understand how to incorporate DevOps in your organization. The focus of DevOps metrics is on deployment, operations, and support (feedback). Let us have a look at the Devops metrics which will lead to improved delivery performances. People: People are the major elements of the DevOps process. People-oriented metrics measure the things like yielding, capacity and response time. People are the hardest element of DevOps. So always start with the phase ‘People’. Process: In some ways, DevOps is considered as a process of  continuous deployment. There are many process-oriented metrics. Development to deployment is a large process-oriented metrics. Process metrics can be the measurement of speed, appropriateness and effectiveness. Technology: Technology metrics also plays a major role in DevOps. It measures the things like uptime (time during which the computer performs operations), network and support, and failure rate. Deployment (or Change) Frequency: DevOps metrics includes continuous deployment. Updated software deployment in every few days can be possible with fast feedback and piecemeal development. In a DevOps environment, deployment frequency can be measured in terms of the response time, the teamwork, the developer capacities, development tools and the overall efficiency. Change Lead Time: Change lead time is the time period between the initialization phase to the deployment phase. In DevOps, it is a measure of development process efficiency, code and the development systems’ complexity, and also of team capabilities. A protracted ‘change lead time’ is an indicator of an inefficient deployment system. Change Failure Rate: One of the main goals of DevOps is to do frequent deployment with less failure rates. Failure rates metrics should be decreased over time, as the experience and the capabilities of the team and developers get increased. If the frequency of failure is very high, it is definitely a red flag, as it gives rise to problems in the overall DevOps process. Mean Time to Recover: Time taken between ‘recovering the failure’ from the ‘failure’ is known as Mean Time to Recover (MTTR). It can be fragmented into three phases- detection, diagnosis and recovery phases. MTTR metrics is the sign of a good teamwork which identifies how effectively the teams handle the changes, and also, how collaboratively they do so. By all means, this metric is becoming a trend for DevOps to remodel organizational processes in a better way.
Metrics that matters for DevOps Success
Blogs
635
Metrics that matters for DevOps Success

DevOps is generally introduced for the development... Read More

Agile and DevOps Or Agile vs DevOps: Differences

Agile is the standard in today’s application development world. Development teams are adopting it over the last 10 years, as it has been proved to be more efficient methodology of getting quality software. Agile has improved user experience by frequently rewarding with focussed goals and quick delivery. In addition to this, the broad use of DevOps in Agile methodology has made it a more compelling approach for IT commercials. In this context, it is important to know that Agile is not DevOps, and DevOps is not Agile. It is difficult to achieve success in DevOps, if Agile practices are not followed. While Agile can make sense independent of DevOps, it can be more complete when accompanied by DevOps practices.Here are the emerging Agile and DevOps Trends. Many people have set their minds about Agile, that Agile means Scrum and DevOps means continuous delivery. This simplification creates unnecessary confusion between Agile and DevOps, making people think that they are perfectly compatible. So, let us have a look at the practical connections between Agile and DevOps. Planning for Unplanned work: In the DevOps circle, those using Agile acknowledges that Scrum is used to track the planned work. Tasks like releasing updated system, performing system upgrades etc, can be planned. On the other hand, the operations like performance spikes, system expiry, and standard security, can be unplanned. These types of tasks need immediate response. You cannot wait for the next sprint planning session. For this reason, many organizations embrace DevOps (more than Scrum and Kanban), which helps to track both kinds of work. Before, there were priorities from multiple masters, but now a single set of priorities are in use. Similarly, for a long list of assigned work, the time period is planned to accomplish the work. These lightweight management practices by Scrum make a huge difference for a team. Speed vs Risk: Teams using Agile with or without DevOps have to remember that, to support the rapid change, a sound application structure and a solid foundation are mandatory. Applications must have good underlying framework that must be used constantly by the team members. In the DevOps context, the teams must make sure that the changes which are made to the architecture should not introduce any risk. Also, there should not be any hidden side-effects associated with the changes, because the iterative process consists of regular changes in the architecture. So you should be concerned about the risks associated with each and every change made. Only with this type of work will you get rapid delivery without any risk. Agile and Quality: Both Agile and DevOps help develop an application fast, keeping sound structure and risk-free application.  But neither of them concentrates on the quality of the product. Mostly, IT organizations rely on the ‘fail fast’ principle- “ Early failures cost less to fix”. But with this, only fast deployments can be maintained, not quality. Agile produces applications that fit better with the desired requirements and can adapt quickly to respond to the requirement changes made on time, during the project life. DevOps, along with the automation and early bug removal, contributes to creating better quality. Developers must follow Coding and Architectural best practices to  embed quality in the applications. Agile and DevOps should try reach the next level to become highly effective within the organizations. They must conform to the industry standards using Agile and DevOps practices, to allow the development team to improve quality, make delivery faster and avoid software risks.
Agile and DevOps Or Agile vs DevOps: Differences
Blogs
1443
Agile and DevOps Or Agile vs DevOps: Differences

Agile is the standard in today’s application dev... Read More

CSPO Series

Useful links