Search

SAFe Release Planning- Know Your Capacity Constraints

As an Agile Coach in a Scaled Agile Framework® (SAFe®) implementation environment, I have, to the best of my knowledge, explained about the capacity constraints that need to be considered during the Program Increment Planning. In this article let us focus on how the key event in Scaled Agile Framework (SAFe), known as Program Increment (PI) is conducted and understand how recognizing the underlying capacity constraints helps the team plan and commit better. Release Planning – Agile Team: Release planning is a process where the Agile team along with Scrum Master, Product Owner and key stakeholders collaborate to deliver a product increment at regular intervals - typically 2 to 3 months. The Product Owner shares the vision to the team along with a prioritized list of Features that he/she feels can be included in the release. The Agile team works together in splitting the Features to User Stories, estimating Size, and discussing issues & concerns with the Product Owner. They highlight risks, tentatively park the stories across iterations based on the historical velocity that the team can achieve and then arrive at & commit to the release schedule.   Program Increment in SAFe Release Planning in Scaled Agile Framework is a two-day timeboxed event and is called a Program Increment.  “Program Increment (PI) Planning is a cadence-based event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision. PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe” –  Scaled Agile Inc., Why PI Planning? This focussed and dedicated two-day event brings together the entire Agile Release Train(s) into a common forum and more importantly imforms every individual in the train towards the alignment of development to business goals with the business context, program objectives and to understand the direction of the business. The PI planning event corroborates multiple teams within and across ART(s) to discuss, empathize and structure the flow of work that can be taken up for the upcoming PI duration (typically 8 to 12 weeks). PI planning establishes face to face communication of all the team members and stakeholders and also matches demand to capacity by eliminating excess Work in Progress(WIP). PI Planning MeetingImage SourceLet us look briefly at the sequence of activities that are involved in the 2-day Program Increment event. Pre-work: Epics broken down into Features Value (outcome) identified for each feature, analysed and prioritized (example using WSJF) Approximately top 10 features identified for the upcoming PI Day 1 Agenda: Business context set by the business owner Product solution goals set by the product management team Technical/Development goals set by the technical architect team RTE setting the Planning context and agenda Teams breakout to break the features into stories, estimate (story point sizing), determine capacity and load for each iteration, identify risks and dependencies within & across ART(s) and submit draft plan for review Management review and problem solving Day 2 Agenda: Based on the management meeting outcome on day 1, any changes required are discussed. Teams breakout to make any modifications in the scope and replan. Teams bring the PI objectives to the program board.  Business owners assign business value against the PI objective(s).  Final plan is reviewed. Program risks and dependencies are updated in the program board. Teams discuss and decide on the ROAM (Resolved, Owned, Accepted and Mitigated) to see if they can overcome the risk. Confidence vote is taken with respect to the overall planning and commitment. Retrospective is held with respect to the entire PI planning event and any improvement items is taken up for the next PI planning event. This is facilitated and owned by Release Train Engineer (RTE).  Principles of Program Increment Why, What and How? Requirements are rather discovered with the entire Agile Release Train(s) or ARTs that includes the development teams, Product Owners and other stakeholders collaborating on “why” the product/solution is being built. The teams get to know the customer needs better and decide on “what” needs to be built by prioritization. Cross teams within an ART and cross ART dependencies are discussed. Architectural runway - which is the existing code, components and technical infrastructure needed to implement the near-term features without excessive redesign – paves the way for the ART development teams to discuss alternatives, risks and any unknowns to create a view of “How” the increment will be addressed. There are multiple time-boxed activities within this two-day event that allow the teams in the ART(s) to breakout and have a focussed interaction. This approach fosters focus on just enough detail and allows the “spacing effect” and time for reflection The central principle of release planning is the capacity constraint. We will discuss this in the next section. Knowing your capacity constraints during Program Increment Planning Creating a stable and high performing Agile team within an ART depends on how well the team or ART self-manages the capacity constraint. The reason I say self-manage is because this no longer involves resource levelling or critical path techniques that any seasoned project manager would apply. In Scaled Agile, it is just not about the team capacity, it is about the capacity of the Agile Release Train(s). At the team level, one way to determine the capacity to allocate stories in the sprint is by calculating the velocity – that is how many story points can a team deliver during an iteration. Simple way to calculate velocity is to take an average of the story points that were accepted in the previous 6 to 10 iterations/sprints. The capacity is arrived based on the following: Normalizing Story Point estimation across the Agile Release Train In standard Scrum, each team’s velocity is independent of other teams. It is of no concern when one agile team has a velocity of 100 SP per iteration and another agile team has a velocity of 30 SP per iteration. However, in Scaled Agile Framework, when entire Agile Release Train(s) are involved in planning for the PI duration, it is important that the normalized story point estimation is use. Feature capacity Component capacity Other BAU activities the team may need to perform Focus Factor Need to consider focus factor for anything that cannot be planned like any unplanned time loss keeping in mind the daily time off, adhoc unplanned meetings, other official activities, training, Discussion with SME etc Holidays/vacation etc Situation with example  How do we apply normalized story points for Agile Release Trains? Here is an example. Assume a two-week sprint has 10 days. For every full-time person on the team allocate 8 Story Points. (Adjust for part-time). Exclude the Product Owner and Scrum Master. The 8 points is derived from 1 point per day, for 10 days in a 2-week sprint, at 80% capacity Subtract one point for every team member vacation day, public holiday, training day etc. Find a small story and give 1 story point to it. Estimate every other story relative to that one. In a similar fashion, all agile teams in the train estimate the size of work.  Situation: The product management team of an ecommerce division has prioritized a list of Features/Capabilities that are potential candidates for the upcoming PI. Let us assume that the deliverables are not just the features, but there are some components as well that need to be developed to support those features.  The following table represents the capacity constraints for the features/components with the WSJF prioritization FeatureFront EndM/W ComponentB/E ComponentWSJFFeature 170201019.0Feature 26010012.0Feature 3751556.8Feature 46501015Feature 5900511.5Feature 61201008Feature 7190057Arch 10252510Assuming the Agile Release Train(s) capacity is 500 Story Points(where the focus factor, holidays, BAU activities are considered), let us look at what the ART can deliver for the PI based on the above table: Total capacity for ART = 500 SP Based on the above table considering the WSJF, the ART(s) can consider the following to be taken up for the PI. Feature 1 = 100 SP Feature 4 = 75 SP Feature 2 = 70 SP Feature 5 = 95 SP Arch 1 = 50 SP Feature 6 = 120 SP ConclusionAgile Release Train(s) always find it challenging when it comes to commitment based on the capacity constraints during every Program Increment, especially if the train(s) are involved in planning for the first time. However, irrespective of whether teams in the Agile Release Train(s) are composed of feature or component teams, if the capacity constraints are carefully evaluated and on loading the iterations accordingly as mentioned in this article, the teams can be confident of committing to the product management team on what work will be completed during the Program Increment.

SAFe Release Planning- Know Your Capacity Constraints

9K
SAFe Release Planning- Know Your Capacity Constraints

As an Agile Coach in Scaled Agile Framework® (SAFe®) implementation environment, I have, to the best of my knowledge, explained about the capacity constraints that need to be considered during the Program Increment Planning. 

In this article let us focus on how the key event in Scaled Agile Framework (SAFe), known as Program Increment (PI) is conducted and understand how recognizing the underlying capacity constraints helps the team plan and commit better. 

Release Planning – Agile Team: 

Release planning is a process where the Agile team along with Scrum Master, Product Owner and key stakeholders collaborate to deliver a product increment at regular intervals - typically 2 to 3 months. The Product Owner shares the vision to the team along with a prioritized list of Features that he/she feels can be included in the release. The Agile team works together in splitting the Features to User Stories, estimating Size, and discussing issues & concerns with the Product Owner. They highlight risks, tentatively park the stories across iterations based on the historical velocity that the team can achieve and then arrive at & commit to the release schedule.   

Program Increment in SAFe 

Release Planning in Scaled Agile Framework is a two-day timeboxed event and is called a Program Increment.  

Program Increment (PI) Planning is a cadence-based event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision. PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe” –  Scaled Agile Inc., 

Why PI Planning? 

This focussed and dedicated two-day event brings together the entire Agile Release Train(s) into a common forum and more importantly imforms every individual in the train towards the alignment of development to business goals with the business context, program objectives and to understand the direction of the business. The PI planning event corroborates multiple teams within and across ART(s) to discuss, empathize and structure the flow of work that can be taken up for the upcoming PI duration (typically 8 to 12 weeks). 

PI planning establishes face to face communication of all the team members and stakeholders and also matches demand to capacity by eliminating excess Work in Progress(WIP). 

PI Planning Meeting

PI Planning Meeting

Image Source

Let us look briefly at the sequence of activities that are involved in the 2-day Program Increment event. 

  • Pre-work: 
    • Epics broken down into Features 
    • Value (outcome) identified for each feature, analysed and prioritized (example using WSJF) 
    • Approximately top 10 features identified for the upcoming PI 
  • Day 1 Agenda: 
    • Business context set by the business owner 
    • Product solution goals set by the product management team 
    • Technical/Development goals set by the technical architect team 
    • RTE setting the Planning context and agenda 
    • Teams breakout to break the features into stories, estimate (story point sizing), determine capacity and load for each iteration, identify risks and dependencies within & across ART(s) and submit draft plan for review 
    • Management review and problem solving 
  • Day 2 Agenda: 
    • Based on the management meeting outcome on day 1, any changes required are discussed. 
    • Teams breakout to make any modifications in the scope and replan. Teams bring the PI objectives to the program board.  
    • Business owners assign business value against the PI objective(s).  
    • Final plan is reviewed. 
    • Program risks and dependencies are updated in the program board. Teams discuss and decide on the ROAM (Resolved, Owned, Accepted and Mitigated) to see if they can overcome the risk. 
    • Confidence vote is taken with respect to the overall planning and commitment. 
    • Retrospective is held with respect to the entire PI planning event and any improvement items is taken up for the next PI planning event. This is facilitated and owned by Release Train Engineer (RTE).  

Principles of Program Increment 

  • Why, What and How? 
    • Requirements are rather discovered with the entire Agile Release Train(s) or ARTs that includes the development teams, Product Owners and other stakeholders collaborating on “why” the product/solution is being built. 
    • The teams get to know the customer needs better and decide on “what” needs to be built by prioritization. Cross teams within an ART and cross ART dependencies are discussed. 
    • Architectural runway - which is the existing code, components and technical infrastructure needed to implement the near-term features without excessive redesign – paves the way for the ART development teams to discuss alternatives, risks and any unknowns to create a view of “How” the increment will be addressed. 
  • There are multiple time-boxed activities within this two-day event that allow the teams in the ART(s) to breakout and have a focussed interaction. This approach fosters focus on just enough detail and allows the “spacing effect” and time for reflection 
  • The central principle of release planning is the capacity constraint. We will discuss this in the next section. 

Knowing your capacity constraints during Program Increment Planning 

Creating a stable and high performing Agile team within an ART depends on how well the team or ART self-manages the capacity constraint. The reason I say self-manage is because this no longer involves resource levelling or critical path techniques that any seasoned project manager would apply. 

In Scaled Agile, it is just not about the team capacity, it is about the capacity of the Agile Release Train(s). At the team level, one way to determine the capacity to allocate stories in the sprint is by calculating the velocity – that is how many story points can a team deliver during an iteration. Simple way to calculate velocity is to take an average of the story points that were accepted in the previous 6 to 10 iterations/sprints. 

CAPACITY LOADThe capacity is arrived based on the following: 

  • Normalizing Story Point estimation across the Agile Release Train 

In standard Scrum, each team’s velocity is independent of other teams. It is of no concern when one agile team has a velocity of 100 SP per iteration and another agile team has a velocity of 30 SP per iteration. However, in Scaled Agile Framework, when entire Agile Release Train(s) are involved in planning for the PI duration, it is important that the normalized story point estimation is use. 

  • Feature capacity 
  • Component capacity 
  • Other BAU activities the team may need to perform 
  • Focus Factor 

Need to consider focus factor for anything that cannot be planned like any unplanned time loss keeping in mind the daily time off, adhoc unplanned meetings, other official activities, training, Discussion with SME etc 

  • Holidays/vacation etc 

Situation with example 

How do we apply normalized story points for Agile Release Trains? Here is an example. 

  • Assume a two-week sprint has 10 days. 
  • For every full-time person on the team allocate 8 Story Points. (Adjust for part-time). Exclude the Product Owner and Scrum Master. 
  • The 8 points is derived from 1 point per day, for 10 days in a 2-week sprint, at 80% capacity 
  • Subtract one point for every team member vacation day, public holiday, training day etc. 
  • Find a small story and give 1 story point to it. 
  • Estimate every other story relative to that one. 

In a similar fashion, all agile teams in the train estimate the size of work.  

SituationThe product management team of an ecommerce division has prioritized list of Features/Capabilities that are potential candidates for the upcoming PI. Let us assume that the deliverables are not just the features, but there are some components as well that need to be developed to support those features.  

The following table represents the capacity constraints for the features/components with the WSJF prioritization 

FeatureFront EndM/W ComponentB/E ComponentWSJF
Feature 170201019.0
Feature 26010012.0
Feature 3751556.8
Feature 46501015
Feature 5900511.5
Feature 61201008
Feature 7190057
Arch 10252510

Assuming the Agile Release Train(s) capacity is 500 Story Points(where the focus factor, holidays, BAU activities are considered), let us look at what the ART can deliver for the PI based on the above table: 

Total capacity for ART = 500 SP 

Based on the above table considering the WSJF, the ART(s) can consider the following to be taken up for the PI. 

  • Feature 1 = 100 SP 
  • Feature 4 = 75 SP 
  • Feature 2 = 70 SP 
  • Feature 5 = 95 SP 
  • Arch 1 = 50 SP 
  • Feature 6 = 120 SP 

Conclusion

Agile Release Train(s) always find it challenging when it comes to commitment based on the capacity constraints during every Program Increment, especially if the train(s) are involved in planning for the first time. However, irrespective of whether teams in the Agile Release Train(s) are composed of feature or component teams, if the capacity constraints are carefully evaluated and on loading the iterations accordingly as mentioned in this article, the teams can be confident of committing to the product management team on what work will be completed during the Program Increment.

Krishnakumar

Krishnakumar Kuppusamy

Author

Krishnakumar Kuppusamy is one of the highly experienced Agile Coaches and SAFe Program Consultant (SPC 5.0). He has 24+ years of experience in information technology industry handling both traditional and agile projects. He has worked with companies like Citibank (USA) & Polaris Software at various capacities in project & program management. 

He has worked for ANZ and Ford India, coaching multiple Agile teams in their transformational journey. He is also a freelance trainer, conducted trainings in SAFe/PMP/PMI-ACP/ITIL/CBAP for over 2000+ professionals helping them getting certified and excel in their respective areas. 

Join the Discussion

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

Suggested Blogs

CSPO Vs PSPO: Deciding Between the Two Scrum Certifications

As Mike Cohn puts it:“The Scrum product owner is typically a project's key stakeholder. Part of the product owner responsibilities is to have a vision of what he or she wishes to build and convey that vision to the scrum team. This is key to successfully starting any agile software development project. The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.”In other words, a product owner is a leader responsible for maximizing the value of the products created by a scrum development team.The expertise of product owner is centered around the following:It’s about the productIt’s about understanding product benefitsIt’s about customer experienceIt’s about design thinkingIt’s about collaborationAs Scrum.org puts it:“Product ownership is about more than mechanics: it’s about taking accountability and focusing on value in everything you do. The role of a product owner is to identify, measure, and maximize value throughout your entire product lifecycle.”CSPO® and PSPO™ are two of the premier and globally accepted certifications that help validate the holder’s expertise and skills as a product owner in the Scrum framework. Both relate to product ownership which in turn requires business acumen and competency on product vision and roadmap aspects.The training leading up to each of the two certifications offers a learning of wide array of principles, rules, practices, techniques and practical tools that help product owners become effective and successful.So, how exactly are the two different? Let’s have a lookIf you’re someone who is comfortable with the "business side" of projects, you are probably the right person to aim for a Certified Scrum Product Owner® certification.-Scrum AllianceWhat is CSPO?As defined by the Scrum Alliance, a Certified Scrum Product Owner (CSPO) is someone who has been taught by a Certified Scrum Trainer about the Scrum terminology, practices, and principles that will enable them to fulfill the role of Scrum Product Owner.What is PSPO?PSPO stands for Professional Scrum Product Owner, a course and certification offered by Scrum.org. The Scrum.org mission is “To Improve the profession of Software Development”.Differences between CSPO and PSPOAs we saw above, CSPO is an abbreviation which stands for Certified Scrum Product Owner and it is a certification offered by the Scrum Alliance, specifically for the Product Owner role.PSPO is an abbreviation 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 high- standards of quality. The differences between the two lies in the way of obtaining the two certifications and maintaining/renewing them.Certifications issued by Scrum Alliance are obtained by taking an online exam after mandatory completion of a 2-day training given by a Certified Scrum Trainer. Certifications issued by Scrum.org are obtained by taking an online exam without the prerequisite of attending a training. 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 a training to learn, and to experience what Scrum is about, is always highly recommended.While it is quite easy for the people who are very involved in the Agile community to identify the most recognized certifications, it is not a simple task for those who just forayed into the Agile world.Through this blog, I aim to give you a short overview on the differences between CSPO and PSPO credentials to help you make an informed decision.The CSPO workshop is usually informative about Scrum and Agile although the quality may be variable and would depend, on a large part, on the specific instructor and the materials they provide.The basic Comparison of CSPO and PSPOCSPOPSPOCSPO is offered through Scrum AlliancePSPO is offered through Scrum.orgCSPO has continuing education credit requirements every three years and is renewable.PSPO never has to be renewedAccreditation BodyThe accreditation body of the CSPO and PSPO certifications are as follows:PSPO - Scrum.orgCSPO - Scrum AllianceRenewal of CSPO and PSPO CertificationsPSPO - once earned, credential does not expire and does not require renewal.CSPO - once earned, credential valid for two years. Starting Feb 2019, renewal would require 20 Scrum educational units(earned in last 2 years only) and a renewal fee of USD 100 PricePSPO - 200 USD for certification license only. Attending the workshop could cost around 500 USD.CSPO - 500 USD. The cost varies based on the location from which you attend the workshop.Need for training PSPO - No need to take up a training course.CSPO - To earn CSPO certificate, you must attend 2 days CSPO classroom training from  a Certified Scrum Trainer (CST) from Scrum Alliance.After Exam CertificationOnce you pass the PSPO I exam, you will get industry-recognized "PSPO I" certification, along with a PSPO I logo that you can use to identify your achievement. There is no exam for CSPO, and you will get a certificate from Scrum Alliance on completing the 14-16 hour training from a CST.Passing ScorePSPO - 85%CSPO - None. Activities to be completed to achieve the credential is at trainer discretion. Time limit: PSPO - 60 minutesCSPO - NoneNumber of Questions: PSPO - 80CSPO - NoneFormat: PSPO - Multiple Choice, Multiple Answers and True/FalseCSPO - NoneLanguage: PSPO - EnglishCSPO - NoneDifficulty levelPSPO - IntermediateCSPO - NonePSPO has subsequent complexity levels in the form of PSPO I, II, IIICSPO has subsequent complexity level in the form of A-CSPO. Password Expiration DatePSPO - When you purchase a password, it is set up in Scrum.org system and emailed to you within one business day. All Students completing a PSPO course are emailed a password upon completion of the course (typically within 3-5 business days). No expiration date for passwords.CSPO - Depends on the online workflow set up by the Certified Scrum Trainer.MembershipPSPO - Membership of Scrum.org and the membership do not expireCSPO - 2 Year Membership with Scrum Alliance. You are eligible to join local user groups and social networks, enjoy discounts on global events, search for careers on our online job board, and more.Other benefitsPSPO:  Once you get certified, your name will be listed on Scrum.org.CSPO: Once you receive the credential, your name is listed on Scrum Alliance portal.The verdict:The main aim of the CSPO certification is to understand the working of Scrum and the role of the Product Owner playing in a Scrum team. While the objective of the Professional Scrum Product Owner (PSPO) certification is to develop a solid understanding of the Product Owner to maximize the value of the software products and systems.PSPO has a level of difficulty associated with it. The things which I like about PSPO certification is that the certification does not mandatory require you to attend an in-person workshop. You can prepare all on your own and directly proceed to the examination. Also, PSPO has a lifetime validity. once acquired, no need to renew the certificate. To evaluate the value of any certification we need to consider:How knowledge or competency in a subject is evaluated by the certification assessmentHow rigorous is the assessment processThe cost involved with attaining the certificationThe validity of the certificationBut before you make up a decision on whether to pursue the CSPO or PSPO, remember that while earning certifications is the best way to get noticed by potential recruiters, get your skills endorsed and demonstrate your willingness and commitment to self-improvement, it is also important to prove your worth to your employers by being productive, confident and self- reliant.Note: Please note that the opinions expressed here reflect my personal views only.
6294
CSPO Vs PSPO: Deciding Between the Two Scrum Certi...

As Mike Cohn puts it:“The Scrum product owner is... Read More

Who is the Target Audience for Certified Scrum Master Certification Course?

Who is the target audience for Certified Scrum Master certification course? It is easy to understand the Scrum rules, but it is difficult to implement it in real-time projects. CSM course is the best to learn both in detail. It not only teaches you the principles and practices of Scrum but empowers and energizes you to make meaningful changes. Certified Scrum Master course focuses mainly on the Product Owner, Scrum Master and the Team in a software development company. Who will be benefited from this course? Certified Scrum Master course is helpful for everyone who wants to become smart in implementing Scrum in their organizations. Doing a certification course in Scrum strengthens the Scrum Master's experience.  This learning event is highly productive and effective for both leaders and members. As the course is completely revolving around the Scrum Master role, individuals who are planning to take up this role will get benefited more from this course. There is one reputed company in Denmark that sends all the employees from receptionists to senior management to the Scrum training, in order to make them knowledgeable about Scrum concepts and enhance operations throughout their company.  Target Audience There is no such fixed set of target audience for the Scrum Master Certification course. It is designed not only for Scrum Masters but also for the complete project or product delivery teams and anyone interested to work with the Agile teams. You may be a- Software Engineer Product Manager Project Manager Team Leader Business Analyst Development team member Testers etc. Irrespective of your current designation, there are a few basic qualities you should have as a Certified Scrum Master.    It is best for organizations or teams who need memorable and practical instructions. Even students can join this course to get real-time work experience in Scrum by Certified Scrum Trainers (CST) such as: Understanding Scrum framework Building a backlog Estimating a project Different techniques to improve team productivity Effective, project-proven exercises You will also find a CFO, CIO, or CEO in the Certified Scrum Master training classes and others as well who are intended to expand Scrum throughout their organizations. The State of Scrum in 2017 The 2017 state of Scrum report by Scrum Alliance suggested that most of the successful businesses are using Scrum irrespective of the sizes. Agile and Scrum are not limited to only software and IT departments, they are being applied to different industries such as government, education, manufacturing, banking, and finance. Moreover, some other departments such as human resources, finance, and accounting, sales and marketing reported their ongoing Scrum projects. Here are 3 statistics by Scrum Alliance: 89% of Agile users said that they use Scrum approach. 86% reported that they hold a daily Scrum meeting.  83% reported that Scrum was responsible and important to improve the team’s quality of work. Taking a 2-day CSM course, qualifying the CSM exam, and accepting a license agreement primarily establishes you as a Certified Scrum Master. This certification is a way to tell your peers and the world that you have strong knowledge of Scrum and are fit to work as a Scrum Master.  After all, in the Agile confines, CSM certification is the ultimate answer and the way forward.
1593
Who is the Target Audience for Certified Scrum Mas...

Who is the target audience for Certified Scrum Mas... Read More

Why CSPO Certification Is Important For Your Career

This article looks at how and why the CSPO® Certification is increasingly becoming important for today’s Product Owner (PO). The article briefly discusses on the responsibilities of the PO, how the role is becoming mandatory within the organization in today's Agile landscape, what makes a great PO and about the CSPO Certification.Who is a Product OwnerThe Product Owner is a member of the Product Management / Business team who works closely with and is a part of the Agile team throughout the Sprints/Iterations. The responsibilities of a Product Owner(PO) spans across the aspects of People, Product and Process.PeopleThe PO is a conduit between Business and Engineering teams, acting as the “Voice of the Customer” and “Voice of the Business” to the teams,Is one of the members to create the Product vision and constantly communicates the same to the teams, and Is able to interact and communicate well with all stakeholders (Customer, Engineering , Sales, Marketing, Support etc.)ProductDefines and maintains the team’s Product backlog, Can answer “Why” a requirement has found a place in the product backlog, “Why” it is prioritized and “Why” the Customer wants the features, Can provide insights into what customer problem the requirements aim to resolve, Can provide Customer Journey Maps, User Personas and Real Life Examples, and Can determine the value that the product delivers to stakeholders and identify which product backlog items would deliver the most value.ProcessPrioritizes the product backlog and is able to provide the reasons and justification of prioritization to the teams, Is part of the regular Product Backlog refinements to refine User stories and Acceptance Criteria, Is available to the team throughout the iteration and provides continuous feedback, Seeks continuous feedback from Customers, and Is able to review the features and approve User Stories once they are completed.Significance of the PO roleTraditionally the Business/Product Management teams have suffered with constant shortage of time and conflicting priorities between dedicating time for Engineering teams and Customer facing responsibilities. Usually, the Customer facing responsibilities understandably end up as the higher priority,   leaving very little time for the teams.Earlier, the time dedicated by the Product Manager to Engineering teams was very little and elusive, sometimes limited to only email interactions. The Business teams were located at the customer sites and used to visit the Engineering teams occasionally, interacting with them through email or phone calls. As a result, the product and productivity suffered immensely.With the advent of Scaled Agile Frameworks and industry wide adoption of Agile, the role of the Product Owner has been laid out as a mandate and demands the increase of manpower in Business teams. Dedicated Product Owners are becoming increasingly indispensable and significant within teams. The role of the Product Owner role has come as a big relief for Engineering teams, because they are constantly in touch with the Business stakeholders as well as the team, and can smoothen and streamline communication channels.POs are often co-located with the Engineering teams, attending Daily (Stand up) Meetings, Refinement meetings, Sprint Review, Demos etc. in person with the team. They are also available anytime for quick feedback and queries doing away with time-zone difference and delays. The POs closely work with their Customer facing counterparts in the various customer locations, serving as the liaison between Business Teams and Engineering teams.The PO ‘s role is key for the success of the Agile way of working. It has become a “Must Have” role within the Agile landscape rather than a “Good to have” role. This has created a good demand for the PO role in the Software Industry. With the surging demand for POs in the industry, there are many professionals taking up the discipline of Product Management.  There are professionals from other functions like QA/Project Management/ Development etc. moving into the Product Management discipline as well.Who makes a “Great” PO?Although a PO satisfies all the roles and responsibilities required of his/her role, there are some traits and characteristics that set apart a great PO from the crowd.A great PO has conviction in the Product Vision and knows the priorities of the Business very well, and is able to articulate the same to the Engineering teams. Shows commitment in completing the team’s goals by providing early and timely feedback. A great PO is excellent in communication, able to understand the nuances of the various stakeholders and speaks in each one’s language (Customer, Engineering, Sales, Marketing, Support etc.) Does not take sides but does what is right for the given situation and for the Customers. Is able to say “No” and has the reasons for it.Is not a task master who dictates to the team but a great Influencer who has the answers to “what has to be done” and “why it has to be done”.   Trusts the team to know best on “How” things will be implemented. Negotiates well with the team for the Business but is fair in all interactions with the team winning the team’s trust. Is always curious in terms of the product implementation but does not interfere in the team’s approach of building the product.To really excel at the job, the PO has to constantly upskill and sharpen the tools he/she has to offer. The PO is required to have keen knowledge of the various practices and techniques that are being used by his/her peers in the industry, in order to stay ahead of the competition. The PO needs to be part of a “Community of Practice”, grow his/her network outside the organization and be clued into all the relevant trends in the industry.CSPO CertificationWith the growing demand for the PO role in the market, the Industry naturally creates ways to benchmark standards, uphold quality and nourish promising talent. The CSPO Certification is one such mark of standard and quality. It equips the Product Owner to become better at the job and helps certified individuals to stand out in the crowd. The CSPO course and the CSPO community offers the right environment for the Product Owner to excel in his/her job. The curriculum of the CSPO course is outlined below for your reference.ContentsScrum Basics Understand the Scrum Framework and workflow so that the PO   Agile Principles and Scrum Values Roles and Responsibilities Product Owner role in detail Scrum Master role at high level Team role at high level Product Vision Importance of Product Vision Creating the Product Vision Just enough preparations before creating the Product Vision Qualities of Product Vision Relationship between Product Vision and Product Road Map Estimation Estimation Levels and Techniques Accuracy is more desirable than Precision in Agile Estimation What can go wrong with Estimation   Difference between Estimating and Committing Product Backlog   Understand what Product Backlog is and is not Product Backlog Grooming Prioritization Importance and Benefits of Prioritizing Product Backlog Why everything cannot be Mandatory or Highest Priority Who should Prioritize Prioritization based on Multiple Factors Applying formal approaches to Prioritization   Giving leeway to teams to sequence work after prioritization Release Management Goal Iterative and collaborative Release Planning Quality and Technical Debt Releasing Software early and frequently Measuring velocity and Release Burndown chart Forecasting future releases Sprints Product Owner’s role in Scrum Meetings Collaboration between PO and Scrum Team, between PO and Scrum Master Team Commitment Understand why Sprints are Timeboxed and Protected from other distractions Concept of sustainable paceCareer Prospects and GrowthExisting POsFor people who are already wearing the Product Owner’s hat, the CSPO certification is like one more feather in their resume. Going through this course and certification will fine-tune their skills and help add multiple tools in their toolbox.Aspiring POsIn certain organizations, there might be team members exhibiting and playing the roles and responsibilities of a Product Owner without the role title. They would have acquired all the necessary skill-sets but not the formal official title yet. By attending the CSPO course and earning the CSPO certification they convey their readiness to play the role; and this gives the thrust necessary for their formal recognition into a Product owner’s role.Salary AspectsThe CSPO certification has global recognition and so will result in an increase in the pay package for a certified professional PO.What next for an accomplished CSPO?An accomplished CSPO can further his/her career prospects by taking up the Advanced CSPO course and certification. It will set the stage for the product owner to progress in their career path and play the role in a wider scope. Depending on the Organization type and structure it could be the role of a Product Manager, Product Portfolio Owner/Manager— and for the more adventurous, even the CEO of a startup! Some Product owners might choose to diversify into a Business Analyst role as well.In conclusion, the CSPO has become a benchmark certification for Product Owners in the Software Industry. It will definitely help existing and aspiring POs to sharpen and upgrade their skillsets. It is also a badge of accomplishment and achievement for a Product Owner, not only to set them as a class apart in their own organization, but also in their wider Product Management community.
4321
Why CSPO Certification Is Important For Your Caree...

This article looks at how and why the CSPO® Certi... Read More