Search

The Ultimate Guide to Sprint Planning

The Scrum framework has been popular lately and several studies have provedthat the global share of Scrum is more than 50%. One of the reasons for the phenomenal success of Scrum lies in its ceremonies, one of its key pillars.  Scrum has three critical components that create the structure or a skeleton and provides a way of working to the teams and individual, namely, roles, artifacts, and ceremonies. Scrum has four different ceremonies to support Agile software delivery where the Sprint starts with planning and ends with the retrospective. Let us quickly talk about the four ceremonies and then we will start with our topic of the day and deep dive more into Sprint planning. Daily Scrum The event is intended to bring together everyone in the scrum team and talk about what the accomplished last, what is the plan for today and is there any impediment. This event can be categorized under daily planning and collaborative team effort to attain the scrum goal. Sprint planning This event occurs at the start of the Sprint where the team together decides on the Sprint backlog and gains consensus on the sprint goal. They also talk about the estimation, capacity, risk, dependencies, and the timeline. This event is facilitated by the scrum master and occurs once in every Sprint. Sprint review This is the second last event in the print where the team showcases the entire deliverable they have been working throughout this print. This is the time when the stakeholders look at the finished product and provide their feedback. The event provides an effective platform for a collaborative approach with the client towards software delivery. Sprint retrospective This is one of my favorite events in Scrum, though the ceremony looks simple, if done correctly, it can yield tremendous results. It provides the team with a chance to pause and check which things are working, what is not, and how can they improve moving forward. Scrum ceremoniesEach of the ceremonies can be elaborated more as they are deep and dense. This article serves as an in-depthguide on Sprint planning for Scrum practitioners. The Sprint Planning meeting The What Sprint planning can be thought of as a ‘green flag’ that gives a go-ahead to the train called “Sprint”. The purpose of this meeting is to provide the sprint goal and ‘how’ that can be delivered. This is the first meeting that takes place in a Sprint where the scrum team comes together to create the Sprint backlog within a “time-box”, this time-box depends on the iteration length, if the iteration is of two weeks, the time-box can be up to four hours for a team of seven to nine people.  During the Sprint planning meeting, the product owner describes the objective of the sprint and what product backlog items can be utilized to reach that objective. Consequently, the scrum team decides how to work on ‘how’ to get the goal achieved. The How The sprint planning meeting is divided into two parts, first part, constitutes discussion on the sprint backlog creation and the second part revolves around the capacity and estimation. The product owner must keep the product backlog stays in a healthy state, it is prioritized and has the right requirements for the team to work on. The team should also be aware of their capacity and velocity to make appropriate Sprint commitment. Spring Planning meeting agendaThe Who The spring planning meeting is attended by the product owner, the development team, and the scrum master. All three roles are mandatory to run this meeting.  The product owner defines the objective of the sprint and supports the development team with the product backlog. In turn, the development team talks about ‘how’ to deliver and the approach they could take. They can also inform the product owner if the requirement is not doable (at times, the requirements might not be technologically feasible, in such cases the team can discuss the same with the product owner). The Scrum Master takes up the facilitation of the event, they make sure the team sits with an effective ‘input’ and comes out with an efficient ‘output’. The Inputs The Product Backlog serves as the ‘Input’ for the Sprint Planning meeting. It provides the development team with the starting point as it contains the list of requirements for delivery. The Product Backlog is owned by the product owner and hence the responsibility of keeping it up-to-date falls within their purview. The team starts with the highest priority item in the list, clear doubts (if any) and add it up to the Sprint Backlog. To make proper sprint commitment, the team should know their capacity and velocity. The Outputs The sprint planning meeting intends to generate a sprint goal and backlog. The output also defines the ’how’ approach, which the team will take to reach its goal. The team must understand the value of this event, as this draws a path for sprint success. The Scrum Master can help the team and the product owner to come up with an effective plan through their facilitation skills.Input and output of the Sprint Planning MeetingHow do we prepare for the sprint planning meeting? As with other events, the sprint planning meeting has a set agenda and timebox which the team must follow diligently. A healthy backlog is a key to efficacious sprint planning, which means, the Product Owner always must maintain and keep the backlog updated. The team needs to be aware of the available capacity and the targeted velocity this helps in coming up with the correct commitment during the Sprint planning session. What is a backlog? A backlog is a list of requirements from the client to create the desired product. It contains new features, enhancements, bugs, Infrastructure changes, or any architectural requirement. Any work that is related to a product should be in the backlog.  Backlog items are placed in a prioritized list manner Every item in the backlog has an estimate it can either be a high-level estimate or the exact/close estimate, depending on where it falls in the list. Usually, the top few items in the bucket have more clarity, details, and close estimates as compared to the items down in the list. Determining velocity Velocity is unique for every team; no two teams can have the same velocity. Every organization has a different approach towards velocity, ideally, the teams should take an average of the last five sprints. The average formula works for the teams who have been in the system for long or they have spent at least eight to ten sprints as a team.  Usually, velocity-based planning is done with mature teams who are aware of the product and they are good at process. With new teams, the ideal approach relies on the completed stories vs accepted stories ratio. Determining capacity Capacity is determined by available working hours in the sprint timeline which also takes into consideration, the leaves, any holidays, and contingency hours (if required). Capacity directly impacts the output as a team and helps them during Sprint commitment.  Sprint Planning checklist While Agile development is more of a mindset than a methodology, checklists can help guidetheproduct owner, the development team, and the scrum master as they plan and execute sprints. Sprint planning preparation A few days out from the actual sprint planning meeting: Review product roadmap and vision.  Ask team members to update boards and focus on moving tickets to done.  Run sprint review and retrospective.  Groom product backlog: Make sure every user story has a clear priority, is fully formed, and up to date with context and estimates.  Choose sprint goal.  Create a sprint backlog of enough user stories to fill two sprints. Sprint planning meeting Ensure your entire team is present for the meeting.  Start video call for remote team members.  If needed, clean up old board(s) with team by checking status of open tickets.  Discuss spillovers: Should these be continued or dropped? Move any spill-over tasks into the right buckets.  Set the stage with product and market updates.  Define the sprint goal.  Create a “new sprint”. Discuss the goal and team’s capacity:  Is this realistic? If not, can the team lower the scope?  Worst case scenario the product owner needs to come up with a new sprint goal. A few days out from the actual sprint planning meeting: Discuss proposed sprint backlog: Let the team pick user stories and tasks that match the sprint goal and capacity.  Discuss the definition of “done”.  Break down each user story into individual tasks: Make sure each task has as much information as possible.  Ask whether the scope of work leaves time for unexpected issues.  Ask if the scope of work leaves space to tackle bugs and technical debt.  Move sprint backlog of decided-upon user stories and associated tasks into the sprint board.  Get verbal confirmation from the team that they know what to do.  Set up due dates and times for future scrum meetings.Here is a quick checklist to help you plan the Sprint Plan. You can modify and adapt as necessary.The outcome of the Sprint Planning meeting The planning meeting intends to come up with Sprint goal and sprint commitment which is in the form of Sprint backlog. This backlog contains a list of stories, bugs, enhancements, etc. as required by the product owner. The output of the Sprint planning meeting is also to define the approach, the task, and other activities required to achieve the Sprint goal.  Everything that needs to be done is part of the Sprint backlog, by the end of Sprint planning meeting the team should have a solid plan with the ownership This output is further shared with the stakeholders, management and within the team which not only helps in being transparent but it also supports the team to stay focused. How to get Sprint Planning right Scrum focuses on time boxing and hence Sprint planning also requires control over the time limit for the event. As per the industry standards, a sprint of two weeks should be time-boxed for a maximum of 4 hours. The scrum master is responsible for making sure the team sticks to the timing and helps them in coming up with the plan. Spend planning can be an exhaustive ceremony where the team brainstorms, discusses the requirements and ownership.  With great facilitation skills, the scrum master can ask the team to start with an item they know well and subsequently move forward. The team can utilize various estimation techniques to define a number or a story point for each requirement. They can use T-shirt sizing, poker planning, or any other technique they are comfortable with. For effective estimation, the team needs an environment that is transparent, trustworthy, and open to new ideas. This reminds us of the Scrum values and principles that form the foundation of the framework. Common reasons why Sprint Planning fails Multiple reasons can contribute to scrum planning failure. Let us look at some of the frequent cases: Uncooked backlog Most of the time the product backlog is not up to date and lacks prioritization. In such cases the team struggles in defining the Sprint goal, they face difficulties in defining the Sprint commitment due to lack of clarity and details. Unrealistic expectations Oftentimes teams are required to work on requirements that are not feasible, or the team faces some technological challenge. Over-commitment When the teams do not realize the capacity and their velocity and tend to over-commit, this leads to hurdles in delivery. Beyond Time-box Spending too much time in Sprint planning can also jeopardize the event, the team must follow the time-box, going over minute details is not required. Scrum is an empirical process, which means You do not have to plan everything upfront.   Quick tips for success Set a Goal The Product Owner should come up with a sprint goal and share it with the development team. The goal helps the team and staying focused throughout the sprint, they can also use baby scrum meeting to check if they are on track with the goal. Healthy product backlog If the product backlog is in the Good shape, and has stories in order of priority, the team can start pulling from the top. they can even plan a pre-planning meeting, which is also known as backlog grooming who defines the upcoming sprint backlog. Valuable meeting measures Everyone in the team should have the sprint planning meeting invite and if required it should contain the link to video conferencing in-case of a distributed team. The team should have the data on capacity and velocity, and they understand estimations and prioritization. They can use different colored stickies to represent backlog items for example stories can be represented with green and bugs can be presented with red. As per the discipline, the team should follow timeboxing strictly, they can finish early but to go beyond the time is not recommended.  Best practices in Sprint Planning To course a positive sprint, you need to be very prepared and have a solid understanding of what is practicable to shape with the team you have within the timebox. This is the reason why a sprint planning session is so vital for placing the foundation for an agile development project. Let us touch base on some best practices that the teams can adopt for the smooth running of the scrum event. Strategy for uncertainties During the sprint planning meeting, the team talks about capacity, velocity, and shapes their Sprint commitment around the confident items. Planning for uncertainties not only helps in contingency but it also reduces the upcoming risk that can pose an impediment for the team. Sprint skeleton Laying out the stories or Sprint items in the form of a map helps the team in getting a tentative idea around each deliverable. this also helps in defining the internal dependencies and the teams can better plan by moving them up and down. Building consensus It is important to get the team onboarded together as a single group for the sprint goal. They should understand the importance and the urgency of the deliverable and they are ready to take the ownership, this also requires supporting the teammates. Benefits of Sprint Planning A successful Sprint planning creates a smooth runway for the team to start their work. It provides clarity in terms of commitment, goals, timelines, and ownership. The output of the Sprint planning meeting sets an expectation with both the parties - the scrum team and the stakeholders - on what to expect by the end of the Sprint. It can be visualized as the team pulling a bucket of work from a big pile and focus on delivering that bucket with expected quality. Ready, set, sprint! “A goal without a plan is just a wish.” - French writer and pioneering aviator, Antoine de Saint-Exupéry Done in the right spirit, Sprint planning can do wonders in sprint delivery. All it requires is a focused approach, discipline, few best practices, and a collaborative approach towards a solution.  If you have followed this guide, at the end of your sprint planning session you and your entire team should walk away with: An agreed-upon Sprint Goal and a clear definition of “done” Commitment to a realistic sprint backlog Understanding of the bug fixes and support work included in the backlog Detailed tasks for each user story with an estimation and acceptance criteria Due dates and scheduled scrum meetings Now, all you have to do is the work.Ready to start or grow your Agile career?  Check out our latest courses, learn the skills and get the personalized guidance you need. 

The Ultimate Guide to Sprint Planning

7K
  • by Deepti Sinha
  • 18th Jul, 2020
  • Last updated on 15th Mar, 2021
  • 16 mins read
The Ultimate Guide to Sprint Planning

The Scrum framework has been popular lately and several studies have provedthat the global share of Scrum is more than 50%. One of the reasons for the phenomenal success of Scrum lies in its ceremonies, one of its key pillars.  

Scrum has three critical components that create the structure or a skeleton and provides a way of working to the teams and individual, namely, roles, artifacts, and ceremonies. 

Scrum roles, artifacts and ceremonies

Scrum has four different ceremonies to support Agile software delivery where the Sprint starts with planning and ends with the retrospective. Let us quickly talk about the four ceremonies and then we will start with our topic of the day and deep dive more into Sprint planning. 

Daily Scrum 

The event is intended to bring together everyone in the scrum team and talk about what the accomplished last, what is the plan for today and is there any impediment. This event can be categorized under daily planning and collaborative team effort to attain the scrum goal. 

Sprint planning 

This event occurs at the start of the Sprint where the team together decides on the Sprint backlog and gains consensus on the sprint goal. They also talk about the estimation, capacity, risk, dependencies, and the timeline. This event is facilitated by the scrum master and occurs once in every Sprint. 

Sprint review 

This is the second last event in the print where the team showcases the entire deliverable they have been working throughout this print. This is the time when the stakeholders look at the finished product and provide their feedback. The event provides an effective platform for a collaborative approach with the client towards software delivery. 

Sprint retrospective 

This is one of my favorite events in Scrum, though the ceremony looks simple, if done correctly, it can yield tremendous results. It provides the team with a chance to pause and check which things are working, what is not, and how can they improve moving forward. 

Scrum ceremoniesScrum ceremonies

Each of the ceremonies can be elaborated more as they are deep and dense. This article serves as an in-depthguide on Sprint planning for Scrum practitioners. 

The Sprint Planning meeting 

The What 

Sprint planning can be thought of as a ‘green flag’ that gives a go-ahead to the train called “Sprint”. The purpose of this meeting is to provide the sprint goal and ‘how’ that can be delivered. This is the first meeting that takes place in a Sprint where the scrum team comes together to create the Sprint backlog within a “time-box”, this time-box depends on the iteration length, if the iteration is of two weeks, the time-box can be up to four hours for a team of seven to nine people.  

During the Sprint planning meeting, the product owner describes the objective of the sprint and what product backlog items can be utilized to reach that objective. Consequently, the scrum team decides how to work on ‘how’ to get the goal achieved. 

The How 

The sprint planning meeting is divided into two parts, first part, constitutes discussion on the sprint backlog creation and the second part revolves around the capacity and estimation. The product owner must keep the product backlog stays in a healthy state, it is prioritized and has the right requirements for the team to work on. The team should also be aware of their capacity and velocity to make appropriate Sprint commitment. 

Spring Planning meeting agendaSpring Planning meeting agenda

The Who 

The spring planning meeting is attended by the product owner, the development team, and the scrum master. All three roles are mandatory to run this meeting.  

The product owner defines the objective of the sprint and supports the development team with the product backlog. In turn, the development team talks about ‘how’ to deliver and the approach they could take. They can also inform the product owner if the requirement is not doable (at times, the requirements might not be technologically feasible, in such cases the team can discuss the same with the product owner). The Scrum Master takes up the facilitation of the event, they make sure the team sits with an effective ‘input’ and comes out with an efficient ‘output’. 

The Inputs 

The Product Backlog serves as the ‘Input’ for the Sprint Planning meeting. It provides the development team with the starting point as it contains the list of requirements for delivery. The Product Backlog is owned by the product owner and hence the responsibility of keeping it up-to-date falls within their purview. The team starts with the highest priority item in the list, clear doubts (if any) and add it up to the Sprint Backlog. To make proper sprint commitment, the team should know their capacity and velocity. 

The Outputs 

The sprint planning meeting intends to generate a sprint goal and backlog. The output also defines the ’how’ approach, which the team will take to reach its goal. The team must understand the value of this event, as this draws a path for sprint success. The Scrum Master can help the team and the product owner to come up with an effective plan through their facilitation skills.

Input and output of the Sprint Planning MeetingInput and output of the Sprint Planning Meeting

How do we prepare for the sprint planning meeting? 

As with other events, the sprint planning meeting has a set agenda and timebox which the team must follow diligently. A healthy backlog is a key to efficacious sprint planning, which means, the Product Owner always must maintain and keep the backlog updated. The team needs to be aware of the available capacity and the targeted velocity this helps in coming up with the correct commitment during the Sprint planning session. 

What is a backlog? 

A backlog is a list of requirements from the client to create the desired product. It contains new features, enhancements, bugs, Infrastructure changes, or any architectural requirement. Any work that is related to a product should be in the backlog.  

Backlog items are placed in a prioritized list manner Every item in the backlog has an estimate it can either be a high-level estimate or the exact/close estimate, depending on where it falls in the list. Usually, the top few items in the bucket have more clarity, details, and close estimates as compared to the items down in the list. 

Determining velocity 

Velocity is unique for every team; no two teams can have the same velocity. Every organization has a different approach towards velocity, ideally, the teams should take an average of the last five sprints. The average formula works for the teams who have been in the system for long or they have spent at least eight to ten sprints as a team.  

Usually, velocity-based planning is done with mature teams who are aware of the product and they are good at process. With new teams, the ideal approach relies on the completed stories vs accepted stories ratio. 

Determining capacity 

Capacity is determined by available working hours in the sprint timeline which also takes into consideration, the leaves, any holidays, and contingency hours (if required). Capacity directly impacts the output as a team and helps them during Sprint commitment.  

Sprint Planning checklist 

While Agile development is more of a mindset than a methodology, checklists can help guidetheproduct owner, the development team, and the scrum master as they plan and execute sprints. 

Sprint planning preparation 

A few days out from the actual sprint planning meeting: 

  • Review product roadmap and vision.  
  • Ask team members to update boards and focus on moving tickets to done.  
  • Run sprint review and retrospective.  
  • Groom product backlog: Make sure every user story has a clear priority, is fully formed, and up to date with context and estimates.  
  • Choose sprint goal.  
  • Create a sprint backlog of enough user stories to fill two sprints. 

Sprint planning meeting 

  • Ensure your entire team is present for the meeting.  
  • Start video call for remote team members.  
  • If needed, clean up old board(s) with team by checking status of open tickets.  
  • Discuss spillovers: Should these be continued or dropped? Move any spill-over tasks into the right buckets.  
  • Set the stage with product and market updates.  
  • Define the sprint goal.  
  • Create a “new sprint”. Discuss the goal and team’s capacity:  
  • Is this realistic? If not, can the team lower the scope?  
  • Worst case scenario the product owner needs to come up with a new sprint goal. A few days out from the actual sprint planning meeting: 
  • Discuss proposed sprint backlog: Let the team pick user stories and tasks that match the sprint goal and capacity.  
  • Discuss the definition of “done”.  
  • Break down each user story into individual tasks: Make sure each task has as much information as possible.  
  • Ask whether the scope of work leaves time for unexpected issues.  
  • Ask if the scope of work leaves space to tackle bugs and technical debt.  
  • Move sprint backlog of decided-upon user stories and associated tasks into the sprint board.  
  • Get verbal confirmation from the team that they know what to do.  
  • Set up due dates and times for future scrum meetings.

Here is a quick checklist to help you plan the Sprint Plan. You can modify and adapt as necessary.

The outcome of the Sprint Planning meeting 

The planning meeting intends to come up with Sprint goal and sprint commitment which is in the form of Sprint backlog. This backlog contains a list of stories, bugs, enhancements, etc. as required by the product owner. The output of the Sprint planning meeting is also to define the approach, the task, and other activities required to achieve the Sprint goal.  

Everything that needs to be done is part of the Sprint backlog, by the end of Sprint planning meeting the team should have a solid plan with the ownership This output is further shared with the stakeholders, management and within the team which not only helps in being transparent but it also supports the team to stay focused. 

How to get Sprint Planning right 

Scrum focuses on time boxing and hence Sprint planning also requires control over the time limit for the event. As per the industry standards, a sprint of two weeks should be time-boxed for a maximum of 4 hours. The scrum master is responsible for making sure the team sticks to the timing and helps them in coming up with the plan. Spend planning can be an exhaustive ceremony where the team brainstorms, discusses the requirements and ownership.  

With great facilitation skills, the scrum master can ask the team to start with an item they know well and subsequently move forward. The team can utilize various estimation techniques to define a number or a story point for each requirement. They can use T-shirt sizing, poker planning, or any other technique they are comfortable with. For effective estimation, the team needs an environment that is transparent, trustworthy, and open to new ideas. This reminds us of the Scrum values and principles that form the foundation of the framework. 

Common reasons why Sprint Planning fails 

Multiple reasons can contribute to scrum planning failure. Let us look at some of the frequent cases: 

  • Uncooked backlog 

Most of the time the product backlog is not up to date and lacks prioritization. In such cases the team struggles in defining the Sprint goal, they face difficulties in defining the Sprint commitment due to lack of clarity and details. 

  • Unrealistic expectations 

Oftentimes teams are required to work on requirements that are not feasible, or the team faces some technological challenge. 

  • Over-commitment 

When the teams do not realize the capacity and their velocity and tend to over-commit, this leads to hurdles in delivery. 

  • Beyond Time-box 

Spending too much time in Sprint planning can also jeopardize the event, the team must follow the time-box, going over minute details is not required. Scrum is an empirical process, which means You do not have to plan everything upfront.   

Quick tips for success 

  • Set a Goal 

The Product Owner should come up with a sprint goal and share it with the development team. The goal helps the team and staying focused throughout the sprint, they can also use baby scrum meeting to check if they are on track with the goal. 

  • Healthy product backlog 

If the product backlog is in the Good shape, and has stories in order of priority, the team can start pulling from the top. they can even plan a pre-planning meeting, which is also known as backlog grooming who defines the upcoming sprint backlog. 

  • Valuable meeting measures 

Everyone in the team should have the sprint planning meeting invite and if required it should contain the link to video conferencing in-case of a distributed team. The team should have the data on capacity and velocity, and they understand estimations and prioritization. They can use different colored stickies to represent backlog items for example stories can be represented with green and bugs can be presented with red. As per the discipline, the team should follow timeboxing strictly, they can finish early but to go beyond the time is not recommended.  

Best practices in Sprint Planning 

To course a positive sprint, you need to be very prepared and have a solid understanding of what is practicable to shape with the team you have within the timebox. This is the reason why a sprint planning session is so vital for placing the foundation for an agile development project. Let us touch base on some best practices that the teams can adopt for the smooth running of the scrum event. 

  • Strategy for uncertainties 

During the sprint planning meeting, the team talks about capacity, velocity, and shapes their Sprint commitment around the confident items. Planning for uncertainties not only helps in contingency but it also reduces the upcoming risk that can pose an impediment for the team. 

  • Sprint skeleton 

Laying out the stories or Sprint items in the form of a map helps the team in getting a tentative idea around each deliverable. this also helps in defining the internal dependencies and the teams can better plan by moving them up and down. 

  • Building consensus 

It is important to get the team onboarded together as a single group for the sprint goal. They should understand the importance and the urgency of the deliverable and they are ready to take the ownership, this also requires supporting the teammates. 

  • Benefits of Sprint Planning 

A successful Sprint planning creates a smooth runway for the team to start their work. It provides clarity in terms of commitment, goals, timelines, and ownership. The output of the Sprint planning meeting sets an expectation with both the parties - the scrum team and the stakeholders - on what to expect by the end of the Sprint. It can be visualized as the team pulling a bucket of work from a big pile and focus on delivering that bucket with expected quality. 

Ready, set, sprint! 

“A goal without a plan is just a wish.” - French writer and pioneering aviator, Antoine de Saint-Exupéry 

Done in the right spirit, Sprint planning can do wonders in sprint delivery. All it requires is a focused approach, discipline, few best practices, and a collaborative approach towards a solution.  

If you have followed this guide, at the end of your sprint planning session you and your entire team should walk away with: 

  • An agreed-upon Sprint Goal and a clear definition of “done” 
  • Commitment to a realistic sprint backlog 
  • Understanding of the bug fixes and support work included in the backlog 
  • Detailed tasks for each user story with an estimation and acceptance criteria 
  • Due dates and scheduled scrum meetings 

Now, all you have to do is the work.

Ready to start or grow your Agile career?  

Check out our latest courses, learn the skills and get the personalized guidance you need. 

Deepti

Deepti Sinha

Blog Author

Deepti is an Agile Coach by profession and Freelance Trainer with over 11 years of industry experience working primarily with healthcare & finance clients in delivering business. She has played a wide variety of roles in the graph of her career, whether it be, management, operations or quality. She likes reading fiction, management and loves to write her experiences. Her colleagues mostly describe her as very detail oriented person with a knack of creativity and imagination. And yes, she loves feedback more than her coffee!!

Join the Discussion

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

Suggested Blogs

What is the Difference Between PSM1 and PSM2?

Many of our students want to take a recognized certification to show that they have the skills, knowledge, and experience to excel in the role of Scrum Master.  A popular choice for people wanting Scrum certifications is Professional Scrum Master™. Certificate holders are entitled to use a logo to identify their achievement, along with the certification. If you’ve seen these, or you have colleagues who hold the certification, you might be wondering what the difference is between the two most common levels: PSM I and PSM II.In this article, we’ll explain the concept of PSM I vs PSM II so you can choose the right option for you at this point in your career.What is PSM™?PSM™ is Professional Scrum Master, a certification scheme maintained and managed by Scrum.org.It is made up of 3 levels.PSM I: for those who wish to demonstrate a fundamental level of Scrum mastery.PSM II: for those who wish to prove their underlying knowledge of Scrum principles and show that they can apply these in the real world.PSM III: for those who hold a deep understanding of Scrum practices and can apply them in a variety of complex organizational settings.We’re focusing today on the first two levels as these are the most common. At the time of writing, there are nearly 160,000 PSM I holders and the number continues to grow. Figures from Scrum.org show that only around 1% of PSM I holders go on to take the PSM II assessment, which means this certification can really set you apart from the competition.As more and more projects choose to use Agile and Scrum techniques, there is a growing demand for people skilled in these approaches and who understand the principles required for successful delivery.Core Differences Between PSM I and PSM IIPSM I is perfect for people who want to understand the basics of Scrum thoroughly. The training and study required prior to the assessment make sure that you are comfortable using internationally recognized terminology for Scrum approaches.The assessment tests your ability to understand the Scrum Guide and the concepts of applying Scrum. This level gives you the fundamentals in a way that you can evidence and use.PSM II is the next step for people who want to take it further. It goes beyond being able to evidence that you understand Scrum, and shows that you can use it in the workplace.PSM II holders have a deep knowledge and understanding of the Scrum principles and processes. They understand what sits behind the Scrum framework. And they can apply it all in a complex business context to help drive delivery.Both certificates are industry-recognized and demonstrate your ability to act in the role of Scrum Master on a Scrum team.PSM I focuses on the ‘material knowledge’, whereas PSM II focuses on the ‘practice and real-world situations’.Differences Between PSM I and PSM II Subject AreasAs you’d expect the two certificates do cover different topics. PSM II covers more content and looks at additional areas for Scrum Masters.The table below shows a summary of the categories tested in the assessment by PSM level.CategoryCovered in PSM I AssessmentCovered in PSM II AssessmentScrum frameworkYYScrum theory and principlesYYCross-Functional,self-Organizing TeamsYYCoaching and FacilitationYYDone and UndoneYMaximizing valueYProduct backlog managementYScaling fundamentalsYHere is some more information about each of these category areas.Scrum FrameworkThis topic covers the foundational knowledge of Scrum theory and the major concepts like roles, rules, and time-boxing. This category draws heavily on the Scrum Guide. Scrum Masters not only have to know these details, they also have to be able to explain them to others and facilitate their use on the Scrum team.Scrum Theory and PrinciplesThe questions in the assessment that relate to this topic will test your understanding of the theory of Scrum, principles, and values.TeamsThis topic goes in-depth into the working of cross-functional and self-organizing teams. Scrum Masters need to understand how to get the best out of team members through collaboration, cooperation and continuous reflection and development.Coaching and FacilitationYou’ll learn how the role of the Scrum Master is fundamentally different to a project manager or team leader. Questions on this topic will test your understanding of how to coach and facilitate teams to help them do their best work.Done and Undone (PSM II only)This category tests your understanding of what it means to be ‘done’. This underpins the Scrum purpose of creating in increments.Maximizing Value (PSM II only)Questions on the assessment drawn from this category look at your knowledge of the role and responsibilities of the Product Owner. This person is responsible for maximizing value, and you can best serve him or her as a Scrum Master if you understand the principles of optimizing for value.Product Backlog Management (PSM II only)The product backlog is the source of work for a product and backlog management is an important aspect of the Scrum team’s responsibilities.Scaling Fundamentals (PSM II only)The questions in the assessment that link to scaling test your knowledge of how to scale Scrum in your environment while maintaining technical excellence.Prerequisites for PSM I and PSM IIThere are no prerequisites for candidates who wish to sit the PSM I online assessment. However, it makes sense for you to have done some Scrum Master training so that you have a solid understanding of the fundamentals and the terminology used.PSM I is a prerequisite for taking the PSM II assessment. The second Professional Scrum Master level builds on what is assessed at Level 1, so you need to have successfully taken and passed the PSM I assessment before moving on to the PSM II exam.PSM I and PSM II: Exam DifferencesUnlike some Agile and Scrum courses, there is an online assessment – you can’t simply turn up to the training and walk away with a certificate. This is what makes the PSM certificates so valuable. Employers know that candidates who hold these certificates can use their Scrum knowledge and apply it in situations, and have achieved at least the minimum pass rate on an exam to test exactly that.As we’ve seen, the two Professional Scrum Master certifications cover different topic areas in the assessments. There are other differences in the exams too.The table below summarizes the differences and similarities between the PSM I and PSM II assessments.PSM IPSM IIPassing score85%85%Duration60 minutes60 minutesNumber of questions80 questions80 questionsDifficulty levelIntermediateIntermediateQuestion formatMultiple choice;multiple answer;True/FalseMultiple choice;multiple answer;True/FalseExam format85%85%Exam language85%85%Summary: Scrum Master CertificationsPSM I and PSM II build on each other. While there are differences, they reflect the knowledge and understanding that you have to have at each level. As you’d expect, PSM II builds on what is assessed at the PSM I level. This makes both certificates complementary to each other and a perfect way to advance your career as a Scrum Master.Both certificates have high industry value amongst employers, especially in the IT industry and the area of software delivery. If you work in these fields, and you operate in Scrum teams, having a Professional Scrum Master certification will show your employer that you are committed to professional development and to getting the best possible project results for your business.Find local courses close to you in our online course catalog. You could soon be on your way to a new career as a certified Scrum Master.
1759
What is the Difference Between PSM1 and PSM2?

Many of our students want to take a recognized cer... Read More

The Best Product Development Process

What Is Product Development? Product development relates to the creation of a new product that has some benefit; up-gradation of the existing product; or improvement of the production process, method, or system. In other words, it is all about bringing a change for the better in the present goods or services or the mode of production.  Product development includes the following elements:Creation and Innovation pave the process for new discoveries and the creation of a new product that offers benefits to the consumers. Amendment of the existing products is essential to enhance the past products and to attain perfection. Improvement of the existing production process, methods, and practices helps give customers an improved experience. It is cost-efficient for the organization too. For Example; Apple CEO Steve Jobs envisioned an idea of using a touch screen to interact with a computer, which would allow him to directly type onto the display, instead of using a stylus. This idea of a touch screen was first implemented for the first iPhone that was launched in 2007 in the US. Apple, with its new product development, revolutionized the way we use mobile gadgets.Why Is It So Important to have a Product Development Process? Product development is the procedure for the successful development of new products or adding new features to the current product. In business terms, the product development policy provides a skeleton that aids enhancement of the performance and quality of products.  The approaches outlined below can bring up scores of advantages to help and expand the business in today’s contentious market. Control over productThe development of a product without a decent approach is quite a precarious challenge. To manage and to be sure of success, it is necessary to plan the development of your products or services and this is what the business or organization requires. The planning would help in fulfilling business goals. Enhanced performanceSeveral times, even after spending thousands of dollars on promotion or marketing the product, a business owner faces setbacks because of poor quality of the product. Hence, it is important to monitor the production and other processes to preserve a record of wrongdoings and improve the same. Reduce costCreating and implementing new products leads to additional cost to the company. The owner has to bear a huge cost in the primary stages of product development, but after the execution process, it is noticed that there is a decrease in product development cost.The History of Product Development Processes Product improvement is closely tied to creativity, invention, and insight—and follows the vision of an idea. For example: the present-day Gas stove is the consequence of some ancient human's insight that a fire is created by rubbing two stones together: the rest was product development. According to Michael McGrath (in Next Generation Product Development), keen focus on the development process began late in the 19th century. McGrath divides the time since into "generations" of product development importance. First ending in 1950s, the focus was on commercialization of discoveries; in the second, formalization of product development as a process began, and this lasted until the 1980s. In the third "generation" of product development, corporate management concentrated on getting products to market faster. In the 21st century, according to McGrath, stress had shifted to R&D-based development. All types of strategies to product development proceed to exist side-by-side. As in gambling, no "method" ensures success.Product Development Process Models There are different software development life cycle models defined which are helpful in designing the software development process.  Some important and popular SDLC models supported in the industry are as follows: Waterfall Process Model Iterative Process Model Spiral Process Model V Process Model Big Bang Process Model Agile Process Model RAD Process Model Prototyping Process Models Waterfall ModelThe Waterfall Model is the traditional Process Model. It is considered as a linear-sequential life cycle model. Waterfall model at each stage must accomplish the next phase before and there should be no overlapping phases.Iterative Process Model  Iterative process starts with an easy implementation of a subset of the software requirements and iteratively improves the evolving versions until the full system is implemented.  With every  new iteration, new design modifications are produced and new functional capabilities are added.  Spiral Process Model The spiral model has four phases. A software project repeatedly passes through these phases in iterations called Spirals i.e. Identification, Design, Construct or Build and Evaluation and Risk Analysis. V Process Model The V-model is an SDLC model where execution of processes occurs in a sequential manner in a V-shape. It is also acknowledged as Verification and Validation model. The V-Model is an extension of the waterfall model. Big Bang Process Model The Big Bang model is an SDLC model where we do not follow any definite process. The development begins with the required money and efforts as the input, and the output is the software developed which may or may not be as per customer demand. Agile Process Model Agile product development life cycle promotes frequent inspection and adaptation. The methodologies rely on the experience of small teams and teamwork to address any changes and promote trusted customer collaboration. Agile product development methods begin things in small increments. Iterations are small; typically of one to four weeks duration. RAD Process Model The RAD (Rapid Application Development) model is based on prototyping and iterative development with no special planning involved. The method of drafting the software itself involves the planning required for producing the product. Software Prototype Process Model The Software Prototyping refers to building software application prototypes which illustrate the functionality of the product under development, but may not truly hold the precise logic of the original software.What Is the Product Development Lifecycle? The product life cycle is an influential concept in marketing. It defines the stages a product goes through right from its inception to when it is removed from the market. Not all products relinquish the final stage. Some advance and grow while others rise and fail. The main stages of the product life cycle are: Research & development - Researching and developing the product before it is made available for sale in the market Introduction – Driving the product into the market Growth – When sales are expanding at their fastest rate Maturity – Sales are near their highest, but the percentage of growth is slowing down, e.g. new rivals in market or saturation Decline – Final step of the cycle, when sales begin to fallThis can be illustrated by looking at the sales during the time span of the product.What is a New Product Development Process? The product development method is a well-defined series of steps or stages a company uses to achieve its accomplishment of new offerings. Every company develops new product or services, but product development processes vary considerably from one company to another depending on the industry, the product type, whether the product is an incremental improvement or a breakthrough innovation, and the extent to which you focus on product portfolio management. What are the six steps of a traditional new product development process? A typical product development process of this kind has six steps with five gates. Step 1: Product Discovery  Step 2: Definition of Product Step 3: Product Business Case Development  Step 4: Detailed Product Design  Step 5 Validation/Testing of product developed Step 6: Product Launch Step 1: Product Discovery This initial step or stage of the new product development process is where new product ideas originate. A company forms a small team to study the idea and initial draft of the product, perform market analysis, and explore technical and market risk. The concept is the most important step for new products as this is where the most product ideas come from - and this determines the necessity for the development. If the study or product concept is wrong at the early stage, then not only is time wasted but it also increases opportunity cost.    Step 2: Definition of Product This stage encompasses polishing the definition of the product. The team creates the first comprehensive evaluation of the technology, and the market and business features of the new product concept. Developers and managers review and illustrate the important points of differentiation for the new product. If this process is carried out incorrectly, then it can increase time to market or cause the product to misinterpret the needs of the market. Step 3: Product Business Case Development Action supports the organization’s investment in the development of a product by having the team create a comprehensive business plan. This plan comprises exhaustive market research. The team explores the new product and where the intended product fits within it, and also creates a monetary model for the innovative offering that makes presumptions about market share. Step 4: Detailed Product Design The team outlines and assembles a working prototype of the product. In most cases they alpha-test the archetype, working with customers in an iterative manner; receiving feedback, and incorporating it into the prototype. This step in the new product development process is sometimes called Development, and charters the next step, “Validation/Testing.” Step 5: Validation/Testing of product developed Validation and testing mean ensuring the prototype operates as predicted. It also means verifying the product in the opinions of the customers and markets and testing the viability of the financial model of the product. Step 6: Product launch During the product development process, the team realizes everything required to bring the product to market, including marketing and sales plans.   Gate Reviews Each of these six phases finishes within a gate review where the team gives the management specific, pre-defined deliverables, and displays the outcomes required to move on to the next phase of the product development process.The world is moving away from this waterfall product development approach.  It is extremely process heavy and encourages additional interference from Senior Management.Image sourceMinimum Viable Process: A Modern Approach What value does the planning of a new product development bring to customers? Irrespective of its form-i.e. physical or digital, it should be able to solve the customer’s problem. It doesn't matter how complex the problem would be, but it should deliver a high-quality product that brings value to your customers.  In a nutshell, Minimum Viable Product (MVP) is a variant of a software product that has enough functionalities to satisfy the primary needs of the first users and persuade investors to invest money into it. It is not a fully-grown product, but it can nonetheless bring business privileges and has the potential for additional development.  In other words, an MVP is a working prototype that should: Be fast to build Contemplate all resources (money, developers, etc.) on providing customers with real value Create those features that are important for a product to generate value The theory of an MVP was developed by Eric Ries in his book The Lean Startup. The author believes that the most important factor is to focus on business goals and not on the technology which has only secondary importance. Focus on investigating the market and understand the obstacles your potential customers want to solve.  Any product before it is released to the public is a mere theory. Testing in a real-life scenario is important to collect market feedback and then iterate. Each idea, even the most profound one, brings no business value until it is put into practice. An MVP allows you to verify, without making an ample investment of time and money, if the product attracts new customers when launched.  If your product is successful, continue to develop it so it becomes a foundation for a fully-grown product. When MVP needs improvements to be transformed into a product it should be completely reworked. MVP strategy allows you to considerably shorten your time-to-market.  A Modern, Lean Product Development Process Toyota began its journey with lean product development at Toyota Loom Works. Toyota started manufacturing cars. There were differences in manufacturing conditions between Japan and the USA. Toyota had few skilled engineers and had limited prior experience. Car companies in US employed a well-educated work team and benefited from the research and skill-sets of their engineering teams. To tackle this shortfall in knowledge and experience, Toyota escorted an incremental approach to development that built on their current knowledge and this became the basis of the lean systems. Lean Product Development (LPD) is based on lean thinking and lean principles that originally were developed in lean manufacturing. Lean thinking relates to way of thinking and specific practices that maintain less of everything – less resources, less work-in-process, less time, and less cost – to manufacture a physical product, knowledge product or service product.  The five Lean Thinking Principles are: Define and maximize customer value Identify the value stream and reduce waste Make the value-creating steps flow Empower the team Learn and improve Approach: Creating products that delight customers and meet business objectives. Agile methodology versus Waterfall methodology The waterfall project methodology is a traditional pattern for developing engineering systems that were used in manufacturing and construction projects. When executed in software development, specific tasks completed in one phase need to be assessed and validated before moving to the next phase. It is called a linear and sequential approach, where phases flow downward to the next.  The agile project methodology is an example of an incremental model for software development based on principles that focus more on people, decisions, and manageable responses to change. Planning of the whole project is broken down in small increments or short time spans. Each iteration involves the whole SDLC cycle so that a working product is delivered at the end. Some of the distinct differences are: Agile is an incremental and iterative approach; Waterfall is a linear and sequential approach. Agile distributes a project into sprints; Waterfall distributes project into phases. Agile helps to finish many small projects; Waterfall helps to complete one single project. Agile incorporates a product mindset with a focus on customer satisfaction; Waterfall introduces a project mindset with a focus on successful project delivery. Requirements are planned everyday in Agile, while in Waterfall, requirements are adjusted once at the start. Agile enables requirement changes at any time; Waterfall shuns scope changes once the project starts. Testing is done concurrently with development in Agile; testing stage comes only after the build phase in Waterfall. Testing teams in Agile can take part in specifications change; testing teams in Waterfall do not get involved in specification changes. Agile empowers the entire team to manage the project without a project manager; Waterfall requires a project manager who performs an essential role in every phase. Cross-functional teams Cross-functional collaboration involves people from diverse spheres, bringing together their knowledge, expertise, and experience. The major point is “work-interdependency”. Teams have to work together to accomplish results. Cross-team collaboration has become the demand of continually emerging new technologies, with new competitors scrumming, and companies aspiring to stay on top of the game. The success of a cross-functional team depends on several factors, without which a team would be struggling. Highly motivated team members Teams hold responsibility to achieve the mission Open-minded team members Management to support the team No opposing personal goals Clear priorities or direction Adequate communication Cross-functional collaboration can be a great team building measure and can build a more creative atmosphere. The 8 Benefits of Cross-Functional Team Collaboration are: To bring a gulp of creative ideas Engaged employees Spurring innovative ideas Exercising communication skills Developing management skills Chance to get in leadership roles Break stereotype and benefit from diversity Build better team spiritExample: Product development—Agile methodology (Case Study) Below is the case study of a team that faced issues but managed to implement solutions to resolve the issues and delivered output with high standards Issues Products or Services were not delivered on-time. Rework and burden caused employee stress and customer disappointment Lack of clear and well-defined product development methods Excessive projects in the pipeline; team was small, and resources were spread too thin Projects were continuously reprioritized leading to incompetent resource utilization Lack of clarity to project status The absence and missing of key resources led to inefficient product development Lack of strategic management Poor communication and hand-offs between departments Solution implemented Designed a portfolio management system that managed an appropriate and optimal number of projects based on available resources Acquired a scalable and robust lean product development process with integrated lean/agile techniques Implemented cross-functional teams with designated roles and responsibilities Standardized project management processes and enhanced project clarity across the organization Coached the product management team on maturing product strategies and roadmaps Trained and mentored senior management and project team members What made the solution successful? Active and strong senior management buy-in and support played an important role in implementing the solutions at high standards Built organizational knowledge that can be used in other active projects Projects were kept on hold until resources were available Efficient project planning facilitated proper collaboration within cross-functional teams Product development strategies and roadmaps helped the development team Daily stand-up meetings organized helped cross-functional teams to monitor project work, front and center Accommodated implementation timing based on the organization’s capability Effect or Consequence Within a couple of months, important and high priority projects were completed on-time (some early); the client was hence satisfied The client acquired a major contract from the customer due to improved on-time delivery and this, in turn, ensured more business Enhanced communication and coordination across all departments Senior management was competent to evaluate and prioritize the most important projects  Weekly Reports granted visibility to project status Product development and lean/agile processes are now efficiently embedded into the organization The internal conflicts between team members and departments have declined ConclusionNew product development is about transforming new and uninitiated ideas into workable products. This product will be your brainchild, which will provide a contentious advantage and help monopolize the market.The eight stages of product development may seem like a lengthy process, but they are outlined to save time and resources. New product improvement plans and prototypes are experimented with to assure that the new product will meet target market demands and desires. Implement a test launch during the test or marketing stage as a full market launch would be expensive. Finally, the commercialization stage is meticulously planned to maximize product success. A poor launch will affect product sales and could even affect the reputation and vision of the new product.Hence, A Certified Scrum Product Owner® (CSPO®) is one such certification that helps holders become successful product owners by training them on aspects of on-time delivery of high-value releases and maximizing the ROI.
9576
The Best Product Development Process

What Is Product Development? Product development... Read More

Becoming a SAFe® 5 Program Consultant

“Man must rise above the Earth—to the top of the atmosphere and beyond—for only thus will he fully understand the world in which he lives.” – Socrates Over thousands of years, scientists & architects around the world, have been bewildered trying to understand how the great pyramids of Egypt were erected. The key lay in some extraordinary planning, known only to a few chief architects, who at that time, were one of the most important members of the king’s inner circle and responsible for all the royal work carried out. Although everyone knew ‘who’ built the pyramid, the million-dollar question was, ‘how’ did the chief architect of the pyramid communicate his precision planning techniques to a workforce of around 10,000 men?I know what you are thinking next, but yes, I am going to use this analogy to relate the chief architect of a Pyramid to an SPC (SAFe Program consultant). This analogy for me is relevant, since much like the architects who built the pyramids, the SPCs have an important task, of not only designing & charting out plans to take an enterprise on its path of efficiently scaling Agile but also to ensure, that they clearly communicate the plan to the very last scrum team involved in day-to-day product delivery. So, if you want to be an architect who wants to build a pyramid in your kingdom, oops, sorry got a bit carried away; I meant, if you are willing to become an SPC, who wants to implement SAFe in your Enterprise, then this blog is definitely for you, so please do read on.The role of an SPC:‘With the demand for Certified SAFe® professionals continuing to grow at an accelerated rate—especially among Global 2000 enterprises—the value of an SPC certification is greater now than ever before.’ – Scaledagile.com SAFe Program consultants are lean agile change agents who provide knowledge, share experience and pump in that extra horsepower needed to implement change. They are very much the first point of contact for the executives, when the organization reaches the so-called tipping point, running too many programs, hundreds of delivery teams and pretty much a chaotic situation. SPCs work on this rationale for a significant change.  Most importantly, SPCs are empowered to officially train people on the SAFe Framework which has an obvious multiplier effect on organizational competitiveness by increasing productivity, quality, and time-to-market.  There is also a strong return on investment for these trainings, especially if you are an internal change agent. At the end of the day, a SAFe Program Consultant helps increase employee engagement and fosters continuous learning while helping enterprises achieve better outcomes. Yep, that’s what they do. Amazing, isn’t it?  SPCs in their role should also be looking to address some of the gaps in other frameworks, like the below: Constantly ideate a tangible outcome by design in order to bring up the team's right brain activity. Formulate the possibility of teams & portfolios, ending up creating incremental productivity boosters by effective utilization of the IP sprint, as it’s the official approach to have better chance of disruptive innovation.Key areas of competency:By now I am sure, we all would agree that an SPC is a true servant leader who plays a crucial role in SAFe implementation, by applying the latest expert knowledge. They can correlate to existing enterprise (lean agile) ways of working and help the transformation team to identify the sweet spots to start the SAFe transformation. In order to achieve this, SPCs generally would have a very lean focus area, as shown below. As an SPC, you would be expected to be committed to helping people understand and implement SAFe properly and that too in a servant leadership manner. Many enterprise coaches have mentioned that SAFe isn't the only scaling approach that they work with, but a lot of people say (more often than others) that they do want to implement SAFe but want to keep to the true spirit of Agile and that probably is a key thing to keep in mind for any aspiring SPC candidate. Why should I be an SPC?Well, if I have to be brutally honest, you actually don’t need any specific certification in order to become an agile coach at an enterprise level. However, this only works out if you are well recognised within your organization, as a person who values agile practices and SAFe principles and has the key ability, to contribute to the enterprise level scaling initiatives. For everyone else (at least 90% of us) there is an SPC (SAFe Program Consultant) certification. This course is intended for all those who will be materially and directly involved in a SAFe adoption. This includes practitioners, change agents, and consultants responsible for implementing Agile programs and portfolios as part of an enterprise Lean-Agile change initiative. SPC certification definitely gives you an edge over the competition, as SAFe is pretty popular and in some cases, leads the way to adopt and professionalize aspects of scaling agile. SPC certification holds a lot of market value. It will also give you a deep dive into the SAFe implementation roadmap and its nitty gritty concepts. You will learn all about implementing SAFe in organizations at an enterprise level and how you can support this process in the capacity of consultant or internal change agent.  For e.g. a major concern that is raised against SAFe is the incorrect usage of the IP iteration. Rather than taking a break and finding ways to improve productivity, these iterations are more or less used as a Hardening sprint. Where an effective SPC will come into the picture, is when he/she coaches the team to take this time to do some design thinking, create prototypes to communicate about their business ideas (in most cases, the teams are the ones who know the problems much better as they are closer to it), present them to product VP and get them funded for next planning cycle.  You see the difference straight away, don’t you? These are some important things that an SPC needs to be empowered to take up. So if you are a senior agilist in your organization, instead of cribbing about some of the anti-patterns, why don’t you empower yourself by taking an SPC certification? Food for thought, eh?How to get certified? Given that SPC is an advanced level certification, its mandatory to go through the Implementing SAFe course, details of which can be read through in the following link. This is a 4-day training program, typically a classroom training but given the pandemic situation, a remote training mode (an online course with many practical tools) has been adopted and that too quite successfully. The hours are approximately 6 hours per day and may be extended to an extra course day. Please do expect some detailed case studies (success stories), some pre-reading/ video viewing material sent in advance so that you are better prepared (along with mock tests where applicable). Most of the trainers have quickly transitioned to online courses and they do a great job. Things have managed to move on faster than I thought and its only for the larger good.  However, there are some pre-requisites for taking up the certification, as below: 5+ years of experience in software development, testing, business analysis, product, or project management 3+ years of experience in Agile One or more relevant Agile certificationsThere is also the money factor, yes training & exam costs. For SPC, you may need to spend a min of $3000 (some training academies may offer a discounted price, so please do watch out for that) and then you have to pay $800+ per annum (yes, that is correct!) towards renewal costs. This can take a toll on quite a few but believe me there are many organizations willing to bear these costs for their employees as they understand its importance.Image SourceExam Tips: Here are some tips which you might be interested in, on how to prepare yourself for the SPC exam. Most of the SPC aspirants have applied these tips/tricks and have provided positive feedback that this actually works.  Please ensure that you go through and completely understand the big picture of SAFe.Make sure that you take an effort to sincerely relate it to the enterprise where you are working. Jot down a name in front of each role listed in the big picture and then map it to the relevant functions. Exam study materials – SAFe recommends that you go through multiple resources from the SAFe community platforms. Your trainer will be providing the details.  Attempt the sample tests provided by Scaled Agile, along with the mock tests that your trainer will provide. The practice test is available at no additional charge, and you can take it as many times as you like no matter the outcome (pass or fail). However, it provides the same bank of questions randomized in a different order. Once you have taken the sample tests / practice tests, I would highly recommend that you organize yourself and make some stats to data drive your decision of area of improvement and track progress. Questions are more or less, equally distributed from each level like foundations, portfolio & enterprise. Review the whole workbook and do not skip any slide. Every bullet point has a meaning and complete flow. Don’t even leave the glossaryKnowing your trainer:Whilst you are getting prepared to immerse yourself into the workshop or the exam, also please spend some time on understanding who is going to give you the training. It’s a sound advice, especially to those planning to register to an Implementing SAFe class to become SPCs – please do ask around and make sure you verify your SPCT knows his/her Scrum and Kanban properly. This can be done by checking if they have also obtained related scrum/Kanban specific certifications etc.  The Benefits: ‘Once trained, SPCs have the knowledge, skills, and resources needed to educate and train managers, teams, and the other stakeholders necessary to effectively drive the change. They become a critical part of the sufficiently powerful coalition for the changes needed to drive the next critical move’  - © Scaled Agile, Inc. I think this in itself is a very powerful motivation which can be used to reap further benefits.  As you can see, you clearly can’t ignore the enormous benefits of becoming a SAFe Program Consultant. Given that this certification is a formal recognition world over, it helps in supporting you advance in your professional development and for a few of you an SPC certification may as well be an important prerequisite to even apply for certain assignments. Taking up international assignments will only become that much easier. Since SAFe is so prevalent, an SPC certification will open up huge opportunities. A great SPC would be the one who can guide an organization to balance business agility with predictability; both of which are extremely important to the typical enterprise-scale technology organization. Thanks for your patience and wish you all the very best in your Agile journey. In case you want me to write about any specific topic, please feel free to comment below and I’ll be more than happy to add them to my ‘Blog Backlog’. If you liked the article, please do share it in your agile community to help spread the word.  Hope to see you soon, with more such interesting topics. 
5386
Becoming a SAFe® 5 Program Consultant

“Man must rise above the Earth—to the top of t... Read More