Kickstart your career with best deals on top training courses NY10 Click to Copy

Search

Series List

How Not to be Agile – Ultimate Guide to Sprint Planning

IntroductionHello and welcome to this, the fourth article in the series ‘How Not to be Agile’‘How Not to be Agile’ may seem a strange title for blogs about how good Agile is!  What I intend to do over this series of articles is to share with you the misinterpretations, omissions, and mistakes that people make that significantly reduce the potential benefits when an organisation, or part of it, embark on an Agile Transformation.Last time, I discussed the potential pitfalls with respect to the Product Backlog; this time, I will cover some of the misunderstandings and malpractices that I have come across to do with the ‘development timebox’ planning.  The most often used term for the ‘development timebox’ is the Sprint from Scrum; I will use this and other Scrum terminologies in this article but you can use whatever names you like; I shall put single quotes around Scrum role names to indicate that other names may be used.It is the planning, content and management of the Sprints that is important.I will start with a description of how product development is split into different time periods and then focus on the Sprint Planning ceremony.Product Development TimeboxesFigure 1 represents how an Agile product development is split into different timebox levels:The ‘complete’ product development is a timebox; it has a fixed end date; there may be maintenance periods after the product development is ‘complete’.The features of the product ‘go-live’ in a series of Release timeboxes, the content of each release contributing to the business benefits expected; usually, between 2 and 3 months.The content of each Release is developed in a series of Sprints, more of which below.The production of the artifacts produced in each Sprint may be timeboxed as well if appropriate.There are other ‘models’ that are used; some teams release at the end of each Sprint; Google is set to release new or modified functionality about every minute!Suffice to note here:The ‘High-Level Requirements Analysis’ in the Product Development line represents the activities that I covered in the first articles of this series.The Release timeboxes need to be decided before the development work starts.  It is useful if all Release timeboxes are of the same length but in practice, the first is usually longer than the rest and the last, shorter than rest; it depends on the product and organisation.What is a Sprint?For those who have heard the term ‘Sprint’ but not quite sure what it means, a Sprint is a fixed period of time in which ‘requirements’ are developed from the name to a fully working part of the final product, all done by a fixed size team (see ‘How not to be Agile 3. Product Backlog’ {Insert link to published article} for discussion about ‘The Iron Triangle’)’Having achieved an agreed, prioritised and estimated Product Backlog, the Development Team need to decide how long their Sprints will be; usually 2 to 3 weeks but can be as short a one week or as long as 4 weeks depending on the organisation’s circumstances and the nature of the product to be developed.  If it is thought necessary to have Sprint lengths greater than 4 weeks, then an in-depth analysis of the reasons for this must be made and changes, probably to the organisation, must be implemented so that the Sprint lengths can be reduced; more than 4 weeks between wider stakeholder reviews are too long and can lead to a lot of wasted work.It is worth noting here that once the Development Team has chosen their Sprint length, it remains the same for the whole product development unless something major happens which requires a change to release plans. Let’s see the purpose and steps for an effective Agile Sprint Planning.Sprint Planning DefinitionThere is a popular myth that Agile requires no planning; the ‘Nike’ approach –  ‘Just Do It’.Nothing is further than the truth; there are more planning ‘events’ in any Agile framework than any waterfall method that I have come across; we just plan at different levels.The first ‘ceremony’ of any Sprint is Sprint Planning  whereby the Development Team agree with the ‘Product Owner’ what the Sprint Goal is and which Product Backlog Items (PBI), that will contribute to that goal, will be attempted during the Sprint.Sprint Planning AttendeesIt is important that all of the Development Team, both full and part-time, the ‘Scrum Master’ and the ‘Product Owner’ attend the Sprint Planning as a minimum:The ‘Product Owner’ needs to be there to set the Sprint Goal, agree the PBI to be attempted in business order and agree on the Sprint MVP.The whole Development Team needs to be there because all team members have to agree on the Sprint Plan; if any team member is absent, he/she may feel that the work has been ‘foisted’ upon them and will have reduced motivation to do it.The ‘Scrum Master’ needs to be there to listen to the conversations so that they can keep a ‘fly on the wall’ view of the team during the Sprint and remind any team member that may be straying from the plan.Sprint GoalThis is a widely misunderstood part of Agile; there are many organisations that think that the Sprint Goal is to complete all the chosen PBI; it is not.A Sprint Goal helps the Development Team focus on a narrow aspect of the overall product, for example:“The Sprint Goal is to complete as many of the payment methods as possible”For a ‘retail’ website, there may be many possible payment methods such as credit/debit cards, PayPal, WorldPay etc.  There will no doubt be some ‘common’ aspects to all payment methods that will need to be developed and each method will have its own ‘specialised’ aspects; it is unlikely that all payment methods could be developed in oneSprint unless there was a great deal of reuse from other products.  Therefore, the customers’ most preferred payment methods may be in the Sprint’s MVP; others that cannot be completed in the Sprint go back into the Product Backlog in their respective business value order for consideration in later Sprints.You can think of a Sprint Goal as the Sprint Vision similar to the Product Development Vision that I discussed in the first article in this series. {Insert link to published article}Case Study 1:In one organisation that I coached in, when I arrived, they did not have ‘Sprint Goals’.  The teams worked out their capacity and ‘filled’ the Sprint with PBI estimated to fit that capacity.  The ‘Sprint Goal’ as far as management was concerned was to complete all the PBI in Sprint that was chosen during Sprint Planning.What you have in this situation is fixed time, fixed team and fixed requirements; recognise that? It’s a Waterfall.Because, like all of us, the team members were not that good at estimating, were reliant on external resources that it had no control over and did not know all the SprintBacklog Items (SBI) at Sprint Planning , the teams consistently ‘failed’ to complete all the Sprint Planning chosen PBI  in the Sprint.The immediate consequence of this was management ‘getting on the teams’ backs’ for not working hard enough.  Morale sank and the team members blamed Agile!The teams learned to ‘game’ the PBI estimating by increasing estimates so that less PBI were chosen at Sprint Planning.  One team even marked unfinished PBI as complete at the end of the Sprint and then ‘resurrected’ them for the next Sprint.Lessons:By not having a Sprint Goal, the ‘Product Owners’ lost the chance to focus Sprint development incoherent areasBy expecting Development Teams to complete all published SBI within the Sprint, team morale dropped, the team members blamed Agile and they focused on making themselves look better in the eyes of management rather than producing the best business value.Sprint Planning Inputs1) The Product Backlog:  The initial estimation of the next most important PBI to contribute to the Spring Goal was probably done sometime before Sprint Planning; the Development Team will have learned a lot from previous Sprints so those initial estimates may be way off.Most teams carry out Backlog Refinement during a Sprint to make sure that the next most important PBI are ready to be considered for the next Sprint; I will discuss Backlog Refinement in a later article.If Backlog Refinement is not done separately, it must be done as part of the Sprint Planning.2) Review Comments from the previous Sprint:  There may have been comments of the development to date from the previous Sprint Review session that may affect what needs to be done in the current Sprint.  These may include:High-priority changes required to previously developed PBI; unlikely but not unheard of.Changes to organisation strategy or tactics that mean necessary changes to Product Backlog ordering.Additional PBI that need to be added to the Product Backlog.3) ‘Inspect and Adapt’ Improvements:  The last ceremony of any Sprint is the Retrospective where the team discusses possible improvements to the process they are following and make prioritised plans to implement the improvements.The process improvement items must be considered when the team decides on what is possible in the Sprint; new processes sometimes slow production until they ‘bed-in’.4) The Risk List/Register: One Sprint Planning input that is mostly overlooked is the Development Risk List/Register.  Without going into the detail of Risk Analysis, one of its aspects is to determine when a particular risk may become an issueProbable risks need to be considered during Sprint Planning because any mitigation work that needs to be done will reduce the number of PBI that may be attempted.Sprint Planning Process1) Establish Probable Sprint2) Velocity Sprint Planning starts with the team deciding what their Sprint Velocity is expected to be from the following:Team Sprint Capacity: For most Agile teams, their Sprint capacity is based on the team’s Velocity; the average number of Story Points completed over the last 3 or 4 Sprints.  For organisations ‘wedded’ to time estimation, the team’s Sprint capacity is the number of team members multiplied by the number of working hours in the day multiplied by the number of working days in the Sprint.For teams using Velocity to estimate their capacity, any team member absence during the Sprint must be used to reduce the Velocity with which to plan the Sprint.Risk Analysis:  The Risk List/Register must be reviewed to see if any of the risks may become issues during the Sprint.  If so, then decisions must be made whether to:A) Implement any risk mitigation work in order to prevent the issue.B) Plan what to do if the risk does create an issue.C) ‘Ignore’ the risk if the probability of it causing an issue is low.Again, if the team consider that significant work must be done for managing any risks, then the team Velocity must be reduced to account for the risk management work.Review Comments:  The team must inspect the Review Comments from the previous Sprint Review to see if any remedial work is needed.  If so, the work must be estimated and, again, the team velocity must be reduced.Ideally, Review Comments that necessitate remedial work should become PBI and ordered by the Product Owner before Sprint Planning; if this is the case, there is no need to reduce the team’s Velocity.Inspect and Adapt:  If the team has decided that they will attempt process improvements during the Sprint, it needs to consider if any of these improvements will cause extra work and if so, what effect the extra work may have on the team Velocity.You may think that process improvements should result in a higher Velocity; however, if the process improvement is to do with getting better quality, then the Velocity may go down.Case Study 2:For one engagement, I was working as an analyst/designer and I raised a concern with the ‘Agile PM’ that I could not find the Risk List/Register so that I could add risks as they came up.  He was wary about adding risks because he believed that people would perceive that the more risks there were, the less he was capable of doing his job!After persuading him to let me see the Risk List, I found it to be wholly inadequate; the risks in the List were few, they weren’t ordered and there was no indication of impact severity, probability of becoming issues or when they may occur; there was no mitigation in place for any of them.I persuaded the ‘Product Owner’ that we should have a Risk Workshop with the Development Team and stakeholders.  At the end of the half-day workshop, we had a pretty good Risk List.BUT – the ‘Agile PM’ insisted that he, as the Risk and Issue Manager, would have sole control of it; he would not let anyone see it except himself!As time went on, not being able to see the Risk List, we in the Development Team could not take potential risks into our planning and when risks did turn into issues, we couldn’t see the agreed mitigation.  Progress slowed.LessonsAlways take time before development starts to get a good Risk List/Register not just including the ‘normal’ risks but also including the risks of being Agile in an organisation just beginning to transform.By all means, have the Agile PM/’Scrum Master’ being the sole ‘controller’ of the Risk List; all new risks and changes to existing risks must be passed through the Agile PM/’Scrum Master’ just like the ‘Product Owner’ controls the Product Backlog.The Risk List/Register must be available to the Development Team at Sprint Planning to adequately estimate its Sprint Velocity.2) Establish the Sprint GoalSee above.3) Choose Probable Sprint PBIThe Product Owner should initially choose the next most important PBI that will satisfy the Sprint Goal.The Development Team compare the revised Sprint Velocity with the total Story Points for the initial chosen PBI.The Development Team negotiate with the Product Owner to get the agreed SBI and the Sprint MVP; I discussed the MVP for the Product Backlog in my previous article, ‘How Not to Be Agile 3. Sprint Backlog’; the process to determine the Sprint MVP is the same as for the Product Backlog MVP.Create and publish the Sprint Plan.The team members decide who will do what and when and create the Team/Sprint Board (kanban).4) How Long Should Sprint Planning Take?There is no definitive answer to this question; it depends on the team, the product and the environment.  However, empirical observation of ‘successful’ teams indicates that for a 2-week Sprint, Sprint Planning should take between 2 and 4 hours.Case Study 3:The worst example of ‘non-Agile’ Sprint Planning that I have come across is with the same organisation that I spoke about in Case Study 1 aboveThe Product Backlog was filled in a ‘first come, first served’ order unless a ‘show-stopper’ turned up.There was no Risk Register.There was no Sprint Review Comments because there was no business representation at the Sprint Reviews.There was no ‘Inspect and Adapt’ plans because the teams didn’t really know what Retrospectives were supposed to be for; they held them because they were told to but they used it as a ‘team meeting’ chat.Each team’s Sprint Planning process consisted of:Looking at the next PBI and breaking them down into tasksEstimating the tasks in timeSelecting the PBI whose total estimated time added up to the team’s Sprint time capacity; senior management had ‘allowed’ a ‘contingency’ in that the Sprint time capacity was 80% of the total team time capacity.However, the team member’s task estimation was not done with any enthusiasm because they knew that ‘requirements’ would be arriving in the Sprint that represented between approximately 10% and 50% of the their capacity; there was no pattern to this extra work that could be used to modify the team’s Sprint capacity.What was worse was that senior management measured teams by the number of Sprint Backlog Items (SBI) that had been published in the Sprint Plan; the published list was never completed because of the ‘break-ins’.Each team was taking between 6 and 8 hours to complete Sprint Planning; producing a Sprint Plan that they knew would not work!I asked the teams if they thought their Sprint Planning was ‘reasonable’.  The answer worried me greatly.  The culture of the organisation was ‘what the management wants, the management gets’ and the teams had been used to criticism for years.  The Agile transformation, instigated by the senior management, was an attempt to change this situation but all of the management had probably had less training than the teams.Lessons:When finding ‘bad’ practices in teams, find out the root cause of the ‘bad’ practicesIf, as a ‘Product Owner’, ‘Scrum Master’ or Agile Coach, you do not have access to senior management, introduce a ‘disruptive experiment’; devise an effective Sprint Planning process for one team and when the management ask why things are so different, you will get the access to the management that you need to explain why their ‘edicts’ were probably less than optimal and possibly misinterpreted by the teams.Sprint Planning Output – The Sprint PlanThe Sprint Plan shows:A list of ordered PBI that will be attempted during the Sprint (the SBI) along with the Sprint MVP.A list of workshops that need to involve people outside of the Development Team with the people needed; the list includes dates, times and places for the workshops.A reminder of the Sprint Review date, time and place.The Sprint Plan is published to ALL stakeholders including those who will be required to help during the Sprint.What the Sprint Plan is NotThe Sprint Plan is not:A detailed, day-by-day Gantt Chart of tasks:  What the team does in the way of tasks is for the team onlyThe Team Board – Whether it is ‘Sticky Notes’ on the wall or an electronic representation of that, the Team Board is updated at least daily;  unless something major happens, the Sprint Plan is not changed after publication.Case Study 3:Unfortunately, there is one Agile ‘standards’ organisation that occasionally has a question in its certification exams:Q.  “How often can the Sprint Plan be amended?”A.  “Every day”Rationale.  “The Team Board is updated at least every day during the Daily Stand-up”I guess the organisation has the right to equate a Sprint Plan with the Team/Sprint Board but this has the effect that management and stakeholders need to look at the Board to see what the ‘current’ plan is; they cannot help but interpret the Board with some aspect of Sprint progress and if they do not like what they see, there is a temptation to intervene with the team.Lessons:Progress within a Sprint should be solely the responsibility of the Development Team facilitated by the ‘Scrum Master’.Remember – the sole measure of Sprint success is that the SBI representing the MVP have been completed.ConclusionEffectively preparing for Sprint Planning, following the best practices of Sprint Planning is essential for Sprint success:The ‘Product Owner’ must set the Sprint Goal.All factors influencing the expected team Sprint Velocity must be considered.Initial estimates of PBI done when creating the Product Backlog must be verified in the light of experience gained so far.The Development Team must agree with the ‘Product Owner’ which PBI to take into the Sprint Plan and agree on the Sprint MVP.The Sprint Plan is for the management and stakeholders.The Team/Sprint Board is for the Development Team.
Rated 4.0/5 based on 1 customer reviews
How Not to be Agile – Ultimate Guide to Sprint Planning 182
  • by Steve Ash
  • 08th Oct, 2018
  • Last updated on 14th Feb, 2019
  • 4 mins read
How Not to be Agile – Ultimate Guide to Sprint Planning

Introduction

Hello and welcome to this, the fourth article in the series ‘How Not to be Agile’

‘How Not to be Agile’ may seem a strange title for blogs about how good Agile is!  What I intend to do over this series of articles is to share with you the misinterpretations, omissions, and mistakes that people make that significantly reduce the potential benefits when an organisation, or part of it, embark on an Agile Transformation.

Last time, I discussed the potential pitfalls with respect to the Product Backlog; this time, I will cover some of the misunderstandings and malpractices that I have come across to do with the ‘development timebox’ planning.  The most often used term for the ‘development timebox’ is the Sprint from Scrum; I will use this and other Scrum terminologies in this article but you can use whatever names you like; I shall put single quotes around Scrum role names to indicate that other names may be used.

It is the planning, content and management of the Sprints that is important.

I will start with a description of how product development is split into different time periods and then focus on the Sprint Planning ceremony.

Product Development Timeboxes
Product Development, Releases and Sprints

Figure 1 represents how an Agile product development is split into different timebox levels:

  • The ‘complete’ product development is a timebox; it has a fixed end date; there may be maintenance periods after the product development is ‘complete’.
  • The features of the product ‘go-live’ in a series of Release timeboxes, the content of each release contributing to the business benefits expected; usually, between 2 and 3 months.
  • The content of each Release is developed in a series of Sprints, more of which below.
  • The production of the artifacts produced in each Sprint may be timeboxed as well if appropriate.

There are other ‘models’ that are used; some teams release at the end of each Sprint; Google is set to release new or modified functionality about every minute!

Suffice to note here:

  • The ‘High-Level Requirements Analysis’ in the Product Development line represents the activities that I covered in the first articles of this series.
  • The Release timeboxes need to be decided before the development work starts.  It is useful if all Release timeboxes are of the same length but in practice, the first is usually longer than the rest and the last, shorter than rest; it depends on the product and organisation.

What is a Sprint?

For those who have heard the term ‘Sprint’ but not quite sure what it means, a Sprint is a fixed period of time in which ‘requirements’ are developed from the name to a fully working part of the final product, all done by a fixed size team (see ‘How not to be Agile 3. Product Backlog’ {Insert link to published article} for discussion about ‘The Iron Triangle’)’

Having achieved an agreed, prioritised and estimated Product Backlog, the Development Team need to decide how long their Sprints will be; usually 2 to 3 weeks but can be as short a one week or as long as 4 weeks depending on the organisation’s circumstances and the nature of the product to be developed.  If it is thought necessary to have Sprint lengths greater than 4 weeks, then an in-depth analysis of the reasons for this must be made and changes, probably to the organisation, must be implemented so that the Sprint lengths can be reduced; more than 4 weeks between wider stakeholder reviews are too long and can lead to a lot of wasted work.

It is worth noting here that once the Development Team has chosen their Sprint length, it remains the same for the whole product development unless something major happens which requires a change to release plans. Let’s see the purpose and steps for an effective Agile Sprint Planning.

Sprint Planning Definition

There is a popular myth that Agile requires no planning; the ‘Nike’ approach –  ‘Just Do It’.

Nothing is further than the truth; there are more planning ‘events’ in any Agile framework than any waterfall method that I have come across; we just plan at different levels.

The first ‘ceremony’ of any Sprint is Sprint Planning  whereby the Development Team agree with the ‘Product Owner’ what the Sprint Goal is and which Product Backlog Items (PBI), that will contribute to that goal, will be attempted during the Sprint.

Sprint Planning Attendees

It is important that all of the Development Team, both full and part-time, the ‘Scrum Master’ and the ‘Product Owner’ attend the Sprint Planning as a minimum:

The ‘Product Owner’ needs to be there to set the Sprint Goal, agree the PBI to be attempted in business order and agree on the Sprint MVP.

The whole Development Team needs to be there because all team members have to agree on the Sprint Plan; if any team member is absent, he/she may feel that the work has been ‘foisted’ upon them and will have reduced motivation to do it.

The ‘Scrum Master’ needs to be there to listen to the conversations so that they can keep a ‘fly on the wall’ view of the team during the Sprint and remind any team member that may be straying from the plan.

Sprint Goal

This is a widely misunderstood part of Agile; there are many organisations that think that the Sprint Goal is to complete all the chosen PBI; it is not.

A Sprint Goal helps the Development Team focus on a narrow aspect of the overall product, for example:

“The Sprint Goal is to complete as many of the payment methods as possible”

For a ‘retail’ website, there may be many possible payment methods such as credit/debit cards, PayPal, WorldPay etc.  There will no doubt be some ‘common’ aspects to all payment methods that will need to be developed and each method will have its own ‘specialised’ aspects; it is unlikely that all payment methods could be developed in one
Sprint unless there was a great deal of reuse from other products.  

Therefore, the customers’ most preferred payment methods may be in the Sprint’s MVP; others that cannot be completed in the Sprint go back into the Product Backlog in their respective business value order for consideration in later Sprints.

You can think of a Sprint Goal as the Sprint Vision similar to the Product Development Vision that I discussed in the first article in this series. {Insert link to published article}

Case Study 1:

In one organisation that I coached in, when I arrived, they did not have ‘Sprint Goals’.  The teams worked out their capacity and ‘filled’ the Sprint with PBI estimated to fit that capacity.  The ‘Sprint Goal’ as far as management was concerned was to complete all the PBI in Sprint that was chosen during Sprint Planning.

What you have in this situation is fixed time, fixed team and fixed requirements; recognise that? It’s a Waterfall.

Because, like all of us, the team members were not that good at estimating, were reliant on external resources that it had no control over and did not know all the Sprint

Backlog Items (SBI) at Sprint Planning , the teams consistently ‘failed’ to complete all the Sprint Planning chosen PBI  in the Sprint.

The immediate consequence of this was management ‘getting on the teams’ backs’ for not working hard enough.  Morale sank and the team members blamed Agile!

The teams learned to ‘game’ the PBI estimating by increasing estimates so that less PBI were chosen at Sprint Planning.  One team even marked unfinished PBI as complete at the end of the Sprint and then ‘resurrected’ them for the next Sprint.

Lessons:

  1. By not having a Sprint Goal, the ‘Product Owners’ lost the chance to focus Sprint development incoherent areas
  2. By expecting Development Teams to complete all published SBI within the Sprint, team morale dropped, the team members blamed Agile and they focused on making themselves look better in the eyes of management rather than producing the best business value.

Sprint Planning Inputs

1) The Product Backlog:  The initial estimation of the next most important PBI to contribute to the Spring Goal was probably done sometime before Sprint Planning; the Development Team will have learned a lot from previous Sprints so those initial estimates may be way off.

Most teams carry out Backlog Refinement during a Sprint to make sure that the next most important PBI are ready to be considered for the next Sprint; I will discuss Backlog Refinement in a later article.

If Backlog Refinement is not done separately, it must be done as part of the Sprint Planning.

2) Review Comments from the previous Sprint:  There may have been comments of the development to date from the previous Sprint Review session that may affect what needs to be done in the current Sprint.  These may include:

  • High-priority changes required to previously developed PBI; unlikely but not unheard of.
  • Changes to organisation strategy or tactics that mean necessary changes to Product Backlog ordering.
  • Additional PBI that need to be added to the Product Backlog.

3) ‘Inspect and Adapt’ Improvements:  The last ceremony of any Sprint is the Retrospective where the team discusses possible improvements to the process they are following and make prioritised plans to implement the improvements.

The process improvement items must be considered when the team decides on what is possible in the Sprint; new processes sometimes slow production until they ‘bed-in’.

4) The Risk List/Register: One Sprint Planning input that is mostly overlooked is the Development Risk List/Register.  Without going into the detail of Risk Analysis, one of its aspects is to determine when a particular risk may become an issue

Probable risks need to be considered during Sprint Planning because any mitigation work that needs to be done will reduce the number of PBI that may be attempted.

Sprint Planning Process

1) Establish Probable Sprint

2) Velocity Sprint Planning starts with the team deciding what their Sprint Velocity is expected to be from the following:

  • Team Sprint Capacity: For most Agile teams, their Sprint capacity is based on the team’s Velocity; the average number of Story Points completed over the last 3 or 4 Sprints.  

    For organisations ‘wedded’ to time estimation, the team’s Sprint capacity is the number of team members multiplied by the number of working hours in the day multiplied by the number of working days in the Sprint.

    For teams using Velocity to estimate their capacity, any team member absence during the Sprint must be used to reduce the Velocity with which to plan the Sprint.

  • Risk Analysis:  The Risk List/Register must be reviewed to see if any of the risks may become issues during the Sprint.  If so, then decisions must be made whether to:

    A) Implement any risk mitigation work in order to prevent the issue.
    B) Plan what to do if the risk does create an issue.
    C) ‘Ignore’ the risk if the probability of it causing an issue is low.

Again, if the team consider that significant work must be done for managing any risks, then the team Velocity must be reduced to account for the risk management work.

  1. Review Comments:  The team must inspect the Review Comments from the previous Sprint Review to see if any remedial work is needed.  If so, the work must be estimated and, again, the team velocity must be reduced.
    Ideally, Review Comments that necessitate remedial work should become PBI and ordered by the Product Owner before Sprint Planning; if this is the case, there is no need to reduce the team’s Velocity.
  2. Inspect and Adapt:  If the team has decided that they will attempt process improvements during the Sprint, it needs to consider if any of these improvements will cause extra work and if so, what effect the extra work may have on the team Velocity.
    You may think that process improvements should result in a higher Velocity; however, if the process improvement is to do with getting better quality, then the Velocity may go down.

Case Study 2:

For one engagement, I was working as an analyst/designer and I raised a concern with the ‘Agile PM’ that I could not find the Risk List/Register so that I could add risks as they came up.  He was wary about adding risks because he believed that people would perceive that the more risks there were, the less he was capable of doing his job!

After persuading him to let me see the Risk List, I found it to be wholly inadequate; the risks in the List were few, they weren’t ordered and there was no indication of impact severity, probability of becoming issues or when they may occur; there was no mitigation in place for any of them.

I persuaded the ‘Product Owner’ that we should have a Risk Workshop with the Development Team and stakeholders.  At the end of the half-day workshop, we had a pretty good Risk List.

BUT – the ‘Agile PM’ insisted that he, as the Risk and Issue Manager, would have sole control of it; he would not let anyone see it except himself!

As time went on, not being able to see the Risk List, we in the Development Team could not take potential risks into our planning and when risks did turn into issues, we couldn’t see the agreed mitigation.  Progress slowed.

Lessons

  • Always take time before development starts to get a good Risk List/Register not just including the ‘normal’ risks but also including the risks of being Agile in an organisation just beginning to transform.
  • By all means, have the Agile PM/’Scrum Master’ being the sole ‘controller’ of the Risk List; all new risks and changes to existing risks must be passed through the Agile PM/’Scrum Master’ just like the ‘Product Owner’ controls the Product Backlog.
  • The Risk List/Register must be available to the Development Team at Sprint Planning to adequately estimate its Sprint Velocity.

2) Establish the Sprint Goal

See above.

3) Choose Probable Sprint PBI

  • The Product Owner should initially choose the next most important PBI that will satisfy the Sprint Goal.
  • The Development Team compare the revised Sprint Velocity with the total Story Points for the initial chosen PBI.
  • The Development Team negotiate with the Product Owner to get the agreed SBI and the Sprint MVP; I discussed the MVP for the Product Backlog in my previous article, ‘How Not to Be Agile 3. Sprint Backlog’; the process to determine the Sprint MVP is the same as for the Product Backlog MVP.
  • Create and publish the Sprint Plan.
  • The team members decide who will do what and when and create the Team/Sprint Board (kanban).


4) How Long Should Sprint Planning Take?

There is no definitive answer to this question; it depends on the team, the product and the environment.  However, empirical observation of ‘successful’ teams indicates that for a 2-week Sprint, Sprint Planning should take between 2 and 4 hours.

Case Study 3:
The worst example of ‘non-Agile’ Sprint Planning that I have come across is with the same organisation that I spoke about in Case Study 1 above

  • The Product Backlog was filled in a ‘first come, first served’ order unless a ‘show-stopper’ turned up.
  • There was no Risk Register.
  • There was no Sprint Review Comments because there was no business representation at the Sprint Reviews.
  • There was no ‘Inspect and Adapt’ plans because the teams didn’t really know what Retrospectives were supposed to be for; they held them because they were told to but they used it as a ‘team meeting’ chat.

Each team’s Sprint Planning process consisted of:

  • Looking at the next PBI and breaking them down into tasks
  • Estimating the tasks in time
  • Selecting the PBI whose total estimated time added up to the team’s Sprint time capacity; senior management had ‘allowed’ a ‘contingency’ in that the Sprint time capacity was 80% of the total team time capacity.

However, the team member’s task estimation was not done with any enthusiasm because they knew that ‘requirements’ would be arriving in the Sprint that represented between approximately 10% and 50% of the their capacity; there was no pattern to this extra work that could be used to modify the team’s Sprint capacity.

What was worse was that senior management measured teams by the number of Sprint Backlog Items (SBI) that had been published in the Sprint Plan; the published list was never completed because of the ‘break-ins’.

Each team was taking between 6 and 8 hours to complete Sprint Planning; producing a Sprint Plan that they knew would not work!

I asked the teams if they thought their Sprint Planning was ‘reasonable’.  The answer worried me greatly.  The culture of the organisation was ‘what the management wants, the management gets’ and the teams had been used to criticism for years.  The Agile transformation, instigated by the senior management, was an attempt to change this situation but all of the management had probably had less training than the teams.

Lessons:

  1. When finding ‘bad’ practices in teams, find out the root cause of the ‘bad’ practices
  2. If, as a ‘Product Owner’, ‘Scrum Master’ or Agile Coach, you do not have access to senior management, introduce a ‘disruptive experiment’; devise an effective Sprint Planning process for one team and when the management ask why things are so different, you will get the access to the management that you need to explain why their ‘edicts’ were probably less than optimal and possibly misinterpreted by the teams.

Sprint Planning Output – The Sprint Plan
The Sprint Plan shows:

  • A list of ordered PBI that will be attempted during the Sprint (the SBI) along with the Sprint MVP.
  • A list of workshops that need to involve people outside of the Development Team with the people needed; the list includes dates, times and places for the workshops.
  • A reminder of the Sprint Review date, time and place.

The Sprint Plan is published to ALL stakeholders including those who will be required to help during the Sprint.

What the Sprint Plan is Not

The Sprint Plan is not:

  • A detailed, day-by-day Gantt Chart of tasks:  What the team does in the way of tasks is for the team only
  • The Team Board – Whether it is ‘Sticky Notes’ on the wall or an electronic representation of that, the Team Board is updated at least daily;  unless something major happens, the Sprint Plan is not changed after publication.

Case Study 3:

Unfortunately, there is one Agile ‘standards’ organisation that occasionally has a question in its certification exams:

Q.  “How often can the Sprint Plan be amended?”
A.  “Every day”

Rationale.  “The Team Board is updated at least every day during the Daily Stand-up”

I guess the organisation has the right to equate a Sprint Plan with the Team/Sprint Board but this has the effect that management and stakeholders need to look at the Board to see what the ‘current’ plan is; they cannot help but interpret the Board with some aspect of Sprint progress and if they do not like what they see, there is a temptation to intervene with the team.

Lessons:

  1. Progress within a Sprint should be solely the responsibility of the Development Team facilitated by the ‘Scrum Master’.
  2. Remember – the sole measure of Sprint success is that the SBI representing the MVP have been completed.

Conclusion
Effectively preparing for Sprint Planning, following the best practices of Sprint Planning is essential for Sprint success:

  • The ‘Product Owner’ must set the Sprint Goal.
  • All factors influencing the expected team Sprint Velocity must be considered.
  • Initial estimates of PBI done when creating the Product Backlog must be verified in the light of experience gained so far.
  • The Development Team must agree with the ‘Product Owner’ which PBI to take into the Sprint Plan and agree on the Sprint MVP.
  • The Sprint Plan is for the management and stakeholders.
  • The Team/Sprint Board is for the Development Team.
Steve

Steve Ash

Blog Author

Steve Ash has been working with ‘Agile’ since 1993 when it was known as ‘Managed RAD’.  He was an early adopter of the DSDM Framework in 1995 becoming a DSDM Board Member in 2002 and was a DSDM examiner.  He is a DSDM Advanced Practitioner and Accredited Trainer/Coach. Steve has since embraced Scrum, Kanban, the techniques advocated by XP, Lean Software Development and Lean Startup. He joined the Agile Alliance in 2002 and is a Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), SAFe® Certified Consultant (SPC4) and certified by APMG International to teach Agile Project Management and Agile Business Analysis courses. Since 1996, Steve has trained, mentored and coached hundreds of people in many public and commercial organisations in 11 countries from the USA, through Europe and India to Asia/PAC.
 

Join the Discussion

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

1 comments

Donald Hope 16 Nov 2018

Very circumstantial info Thanks.

Suggested Blogs

Writing Effective User Stories in JIRA

User stories are one of the main methods of communicating requirements to developers/development team in an Agile project. It is important for the individual tasked with documenting the requirements to be able to write effective and detailed enough user stories. The user stories are required to be comprehensive enough to enable the developer/development team to start analyzing, designing and developing the required functionality, feature or requirement stated in the user story.     This article while intending to guide individuals on how to write effective user stories is also intended to advise on the best practices of creating user stories using JIRA as a requirements management tool for creating stories and tasks. What is a User Story?   User stories are short, simple descriptions of a feature in the system under development told from the perspective of the person who desires this new capability. This person is normally a user of the system or even a customer who pays for the solution.  User stories typically follow a simple template as below. As a , I must be able to so that I can .  User stories are often written on index cards or sticky notes and pasted on an information radiator or in other words a scrum board. This article is however on maintaining user stories using JIRA and on how the tool can be used to ensure regular conversation.  Writing user stories on an index card is actually the ‘Card’ part of the 3 C’s in user stories. It is said that a user story should be long enough to fit into an index card and be detailed enough to arouse discussion. Writing user stories in JIRA A new user story in JIRA can be created by selecting the option to create a new issue of type ‘Story’ as shown below.  The user story in the format listed above can be written in the summary field of the new issue creation screen.  User story definition should satisfy the INVEST criteria which implies that the user stories should be: Independent (of all other user stories and be able to exist on its own) Negotiable (not a specific contract for features but be able to be used to facilitate discussion among relevant stakeholders) Valuable (create some business value) Estimable (to a good approximation) Small (so as to fit within an iteration) Testable (in principle, even if there isn’t a test for it yet)   Trace your Customer Requirements to user stories in Agile through the integration with JIRA. https://t.co/esXyAJykZy pic.twitter.com/DZoa1tJrjL — Visure Solutions (@VisureSolutions) 21 November 2017   JIRA also provides the option to set priority of user stories which might have been done based on the MoSCoW criteria, due dates, assign the story to a team member of the project, allocate a story point/hour based effort estimation for the story, tag the user story to a component level feature or in other words ‘Epic’ and be able to assign the story to a sprint during which the story is required to be implemented. Adding description to user stories The 2nd C of the 3 C’s in user stories that is ‘Confirmation’ is used to specify the acceptance criteria of the user story. An acceptance criterion is used to ascertain when a particular user story can be marked as done and is normally used by the product owner to validate the same. The acceptance criteria also help the development team implement the business rules, functionality and will be the single point of reference for the Quality Assurance Team. The description field in JIRA issue creation provides space for the user to specify the acceptance criteria.   Gearset’s Jira Self-hosted (on-prem) and Jira Cloud integration lets you automatically post deployment updates to your tickets & keep up-to-date with the progress of your user stories. https://t.co/qvDlNK5LLr pic.twitter.com/yh8RmUL1Gm — Gearset (@GearsetHQ) 29 January 2018 Enabling discussion Another main aspect of writing requirements as user stories is to enable conversation about the feature among relevant stakeholders. This is known as the ‘Conversation’ component of user stories which is the 3rd C in the 3C’s.  Often user stories are accompanied with a process diagram, UI wireframe or a mockup, data dictionary etc. which can be added as attachments in JIRA or even be associated with the story as comments, wiki page links maintained in confluence. Conclusion Writing user stories is an easy method of maintaining requirements in a dynamic environment of an Agile project. JIRA, as explained above, provides a powerful and rich set of features which helps manage requirements in an efficient and convenient manner.    
Rated 4.0/5 based on 1 customer reviews
3664
Writing Effective User Stories in JIRA

User stories are one of the main methods of commun... Read More

How To Become A Certified Scrum Master- Exam Preparation And Guidance

Introduction to Certified Scrum MasterWho is the Scrum Master?In one of our previous blog posts, Rumesh Wijetunge shared some relevant insights on the role of Scrum Master. Wearing different hats, coach, enabler, facilitator, team leader, problem-solver, s/he is in charge of giving right directions to team members so that they reach objectives. First promoter of Agile mindset, values and principles, the Scrum Master uses the Scrum framework to help a team in understanding, working on, and achieving a common goal.Responsibilities of the Certified Scrum MasterIt is expected from the Certified Scrum Master to promote an Agile way of working and to lead Scrum implementation in order to improve the team's overall performance. It implies these activities:Teaching Agile values and principles and ensuring they have been understood and adopted by the Scrum Team, and even by the whole organization if possible (and relevant)Implementing the Scrum framework so that it fits  the needs expressed by the Scrum TeamListening, observing and reflecting on how the Scrum Team is reacting to first changes, then selecting and adapting Scrum elements accordingly.Protecting Team Members from any interference or troubles that make them losing focus on their primary workAnticipating, identifying and removing any impediments, and coaching Team Members to learn to solve these situations by themselvesHelping the Product Owner to manage the Product Backlog so that time-to-market is reduced and every increment brings value to end customersActing as a Servant LeaderRequirements to become a Certified Scrum MasterGetting some basic knowledge about the Scrum framework is a nice-to-have prerequisite. However, the first mandatory step is to attend a two-day CSM course conducted by a Certified Scrum Trainer® (CST®). This course will prepare you well for the CSM exam by delivering insights about how to organize and support a Scrum Team. The final step is easy: you need to accept the License Agreement and update your Scrum Alliance membership profile. Why you should be a Certified Scrum Master? Becoming a Certified Scrum Master is one way to expand your career opportunities. Indeed, Agile is spreading everywhere in organisations, in all industries. Strongly correlated, software and digitalization are eating the world, so the need for Scrum Masters in software development is increasing. It is also the beginning of a long journey: it enables you to engage with other Scrum practitioners all over the world, to share best practices, to solve common issues and to promote Agile values and continuous improvement.Besides, this certification offers you to learn foundation of Scrum and scope of the role of Scrum Master. And because it is delivered by Scrum Alliance , this is a very valid proof of your Scrum knowledge.What do I need to do to become a CSM? A true belief and strong interest in Agile philosophy will help for sure to get knowledge, to practice efficiently and to stand out among Agile practitioners. Nonetheless, passing the Scrum Alliance certification for Scrum Master lies mainly in learning Scrum fundamentals and attending to the two-day training (see above paragraph c.)a. Why CSM over PSM: Best Scrum Master certification1. Scrum.org courses- Price, Renewal, Pros, and ConsPrice: It includes exam fees but depends on content, duration, trainer and location:US: $1500Europe: 1500 eurosIndia: INR 26,000Renewal: No expiration (lifetime certification)Pros:Course content is officially designed by Scrum.org so all teachers deliver same content. It implies that Scrum.org selects qualified instructors and ensures students learn the same core content.Exam can be taken without attending course - Exam fees are $150There is an online free assessment exam for practisingCons: Exam is much harder than CSM. It requires experience, and deep theoretical knowledge2. Difference between the Scrum Alliance and Scrum.org coursesThe main difference lies in the fact that Scrum.org provides standard curriculum and course content, while training conducted to become CSM depends on individual trainers experience, opinion and knowledge.CSM Certification TrainingSyllabus of Scrum Master certification Scrum Alliance provides a list of selected resources to learn the Scrum framework. People who want to become Certified Scrum Master are invited to read articles from experts like Mike Cohn or Steve Denning, or from other members. One specific advantage with Scrum Alliance lies in their elearning series: a dozen short videos introduce Scrum Theory and Values, Scrum Roles, Scrum Events and Scrum Artifacts. Besides, it is strongly recommended to read those references:the Scrum Guide by Ken Schwaber and Jeff Sutherlandthe Scrum Primer by Pete Deemer, Gabrielle Benefield, Craig Larman and Bas Voddethe Do Better Scrum by Peter Hundermark Not mandatory but relevant to go further, Scrum: A Pocket Guide by Gunther Verheyenand Software in 30 days by Ken Schwaber.Exam and Certification InformationScrum Alliance courses- Price, Renewal, Pros and Cons The CSM course is a two-day (16 hours) course delivered by a Certified Scrum Trainer® (CST®).There is no standard fee, so the price can vary depending on the context: trainer, content, location, date ; the usual range is from 1000 to 1500 euros (or from 1150 to 1750 dollars).It includes two attempts to take the CSM exam and a two-year membership to the new Scrum Alliance® community. Those two attempts have to be used in the next 90 days after attendees receive the welcome email to pass the test. Beyond this duration, they will be prompted to pay $25 to take the exam. Certification is valid for two years, then it requires to be renewed after that.Besides, attendees to the CSM course will be granted with 14 PDUs credits: 10 PDUs in Technical Project Management and 4 PDUs in Leadership. What can be considered as a drawback is that there is no standard content course. Course materials are made by individual trainers, which implies it can be limited by their experience and opinion.Cost of the Scrum Master CertificationThere is no specific cost for the Certification: fee is included into the CSM two-day course. The structure of the examThe exam is composed of 35 multiple-choice and true/false questions. At least 24 correct answers are required to pass the exam, and there is no time limit to answer those questions. Topics covered in the CSM exam As this exam requires to demonstrate an understanding of the key Scrum elements, it covers general Scrum knowledge, Scrum roles, Scrum meetings and Scrum artifacts.Here are the Sample questions of CSM exam 1) What does NOT belong to the agile manifesto's main pillars?Individuals and interactions over processes and toolsWorking software over comprehensive documentationProcesses over peopleCustomer collaboration over contract negotiationAnswer: Processes over people2) How should work be allocated to the team in an Agile project?The Team Leader (ScrumMaster) should allocate specific tasks to individualsTasks should be randomly allocated to team members, using Planning PokerTeam members should self-select tasks appropriate to their skillsThe most complex tasks should be allocated by the Team Leader (ScrumMaster)Answer: Team members should self-select tasks appropriate to their skills3) What are the disadvantages of the classical waterfall model? (Select the best alternative)A)  End-Product has to be fully anticipated beforehandB)  Some requirements are implemented as defined in the beginning of the project, and yet they are not really needed by the customerC)  Each phase is strictly separated- A- A, B- C, B- A, B, CAnswer: A, B, C4) Who is responsible for prioritizing the product backlog?- Product Owner- Project Manager- Lead Developer- Business AnalystAnswer: Product Owner5) What kind of software development projects can be executed by Scrum Project Management Framework?- Complete software packages- Customer projects- Sub-systems, components or parts of bigger systems- All kinds of software development projects- None of the given answersAnswer: All kinds of software development projectsSalary of the Certified Scrum MasterSalary per year Junior Senior US$82,000 - 105,000$105,000 - 120,000Europe38,000 - 55,000 €55,000 - 75,000 €DubaiAED 25,000AED 35,000IndiaRs. 731,983Rs. 1,424,186
Rated 4.5/5 based on 2 customer reviews
4558
How To Become A Certified Scrum Master- Exam Prep...

Introduction to Certified Scrum MasterWho is the S... Read More

A Journey Towards Earning a Leading Safe® 4.6 Certification

Our blog regularly provides insights about the Scaled Agile Framework (SAFe®), like 4 main features that enable SAFe®. You can also go through an article stating the benefits of SAFe® Agilist certification. Also, we recently published a specific article about the benefits to get the SAFe® 4.5 Certification, and here we give some details about the Leading SAFe® 4.6.What is SAFe®? When any large organization wants to go Agile, it can hardly skip the Scaled Agile Framework ® (SAFe®). Now, this framework has become the world’s leading framework for companies that target to scale Agile. Also, SAFe® is described as the “Agile Enterprise Big Picture”, as it helps to apply Agile and Lean practices and principles to the whole organization, from the Team to the Portfolio level.Benefits of the SAFe® certification For any professional, being SAFe® certified brings recognition to be able to support all kinds of organizations in their Lean and/or Agile transformation. Indeed, SAFe® is the most used framework for scaling Agile, especially in big companies like the ones listed in the US Fortune 100. Consequently, holding a SAFe® certification makes a candidate profile very attractive compared to employers’ expectations.Accreditation body of SAFe®The Scaled Agile Framework® (SAFe®®) has an official certifying body: Scaled Agile, Inc. This accreditation body guarantees “ a valid, reliable, and consistent method of assessing SAFe® skills, knowledge, and mindset “ (read more About SAFe® Certification ).Salary of the SAFe® certifiedSalary for SAFe® certified professionals can vary across regions and experience:EuropeIndiaUnited StatesAgile Coach€ 70,000Rs 2,220,000$135,000Product Owner€ 80,000Rs 1,900,000$115,000Scrum Master€ 55,000Rs 1,220,000$95,000Software Engineer€ 60,000Rs 1,630,000$75,000Job roles/Target audience of the SAFe® certificationThe target audience of the SAFe® certification is wide and covers all these positions:         Executives and Leaders, Managers, Directors, CIOs, and VPs         Development, QA, and Infrastructure Management         Program and Project Managers         Product and Product Line Management         Portfolio Managers, PMO, and Process Leads         Enterprise, System, and Solution ArchitectsStatistics related to SAFe® certification(Note: All the data mentioned here is provided by payscaleEuropeIndiaUnited StatesGenderFemale: 10%Male: 90%Female: 40%Male: 60%Years of experiencePopular companiesDeutsche BankINGBNPViseoPhilipsOmicron4Com TechnologiesMotorolaAir France KLMCA, Inc.Syntel, Inc.Tata Consultancy Services LimitedInfosys LimitedAccentureJohnson ControlsFederal Express Corporation (FedEx)Cap GeminiUsaa InsuranceVencore, Inc.TechSmith CorporationJohnson ControlsSAFe® Agilist Exam detailsWhat is the format of the exam?The SAFe® certification exam is in the Multiple Choice Questions formatHow is the exam delivered?The exam is Web-based (single-browser), closed book, no outside assistance, timed.How to get access to the exam? Once they have completed the Leading SAFe® course, candidates can access the exam. For this, they will use the SAFe® Community Platform. How long is the exam?The exam duration is 90 minutes.How many questions? The SAFe® exam consists of a total of 45 questions.What is the passing score? 34 out of 45 (75% passing score). What is the exam language?English. How much does the exam cost?The course registration fee covers the first exam attempt, provided that the candidate takes the exam within 30 days of course completion. Then, it will cost $50 for any additional attempt.What are the exam prerequisites? There are two main prerequisites to take the exam. First is to have an experience using the Scrum framework, the second is to have more than five years in one or several of these fields: project or product management, business analysis, software development.What is the exam retake policy of the exam?A first retake, meaning a second attempt on the exam, can be done at any moment after a first attempt. In case of a third attempt, candidates have to wait for 10 days and in case of a fourth attempt, they have to wait for 30 days.Leading SAFe® 4.6 Exam preparation SAFe® Agilist Certification exam questionsHere are some of the questions that might be helpful in exam preparation- How to run agile on multiple teams?How to synchronize the work of these teams?How to prioritize organizational demands?How to scale an agile architecture?How to deal with risks in an agile way?Agile and governance, is it possible?Can you highlight the addition and changes in 4-level with 3-level SAFe® 4.0?Can you define a System Team?Can you explain the difference/relationship between a Value Stream and an ART?What is the key to crossing back in forth or connecting the various levels of SAFe®?What is the difference between a Capability and an Epic or Theme?Why would you decentralize decision making? Doesn’t this disempower the product owner or cause confusion about who is the final decision-maker?Are there any reasons that Scrumban would not work with SAFe®?We have some applications that use Scrum delivery practices and some that are milestone driven (waterfall). Can SAFe® 4.0 support both epic and user story management planning, backlog prioritization for Scrum teams, as well as requirements management for our waterfall teams (until they transition to agile)?Some teams may run continuous integrations while others not. How can we balance this if we have a fixed Program Increment timeline?Is SAFe® making it more complex and less agile (e.g., more rigid, additional control)?Exam study materialsKnowledge and skill required by the job role are primarily measured by the exam. In order to prepare well for the exam, candidates can use various online resources like these ones:The course materials are one of the most important components from the course because they offer an opportunity to refer back to the content delivered during the class. All candidates can access to it within the SAFe® Community Platform.The Study guide delivers comprehensive details about the job role and the exam, like a reading list. Here again, it is accessible via the Learning Plan in the SAFe® Community Platform.Another element of the Learning Plan in the SAFe® Community Platform is the Practice test. It offers predictability of success on the exam because it works with similar time duration and level of difficulty and provides the same number of questions.You can go through the SAFe sample test that contains 8 questions that will help you in SAFe 4.6 certification exam preparation.Ways of earning Leading SAFe® 4.6 certificationAttend the courseCourse completion is the first step toward SAFe® certification.Scaled Agile training classes are designed with the learner in mind. Incorporating active learning techniques with a robust role-based curriculum is a great start to the SAFe® learning journey.Receive access to the SAFe® Community Platform after the class, which provides access to study materials & the exam.Study for the examDetailed exam study guides are available to help prepare for the exam and are part of the Learning Plan provided to candidates on the SAFe® Community Platform. Each study guide provides relevant and content-specific exam information, such as the certification role description, prerequisite skills and knowledge, exam objectives, and a comprehensive reading list.Practice tests can help prepare for the exam and are part of the Learning Plan on the SAFe® Community Platform. With a practice test, candidates can ‘test before the test.’ It simulates the actual certification exam in duration, difficulty, and topic area. Passing the practice test does not guarantee to pass the certification exam, but it provides a testing simulation, and the score report can be used to identify an individual’s strengths and weaknesses. Practice tests are available at no additional charge, delivered through the Learning Plan in the SAFe® Community Platform, and can be taken as many times as needed. Note that the testers will receive the same bank of questions each time, but the questions will be randomized.Sample tests provide the examples of the type and format of the questions to expect on the certification exam. They are publicly available for all exams under Exam Details on each certification detail page.Leverage experience. It’s more than being book smart. Scaled Agile exams test specific knowledge, skill, experience, and attitudes related to each SAFe® job role. Combining a person’s learning and studying with their real-world experiences is a key to becoming SAFe®® Certified.Take the ExamA link to the exam is included in the Learning Plan on the SAFe® Community Platform.Candidates have 30 days after course completion to take the exam at no additional charge. However, once they start the exam, they’ll have a fixed time to complete it.Complete exam information, including exam time limit, number of questions, and a sample test, is available for all the exams under Exam Details on each certification official page.What will you get on passing the SAFe® 4 Agilist exam?Becoming a Certified SAFe® 4 Agilist requires an exceptional range of skills and is a career path for many servant leaders (Scrum Masters). SAFe® 4 Agilist certification includes:Getting the Certified SAFe® 4 Agilist PDF certificateGetting the Certified SAFe® 4 Agilist  digital badge. Any candidate can promote their accomplishment onlineNote: Digital badge permits individuals to share authentic certifications online through email signatures, digital resumes, and social media sites such as LinkedIn, Twitter, and Facebook. Digital badging consists of metadata that indicates a Certified SAFe® professional’s qualifications. Scaled Agile has partnered with Acclaim to provide digital versions of SAFe® certifications.Getting one-year membership to the SAFe® Community Platform. It also includes access to the SA Community of PracticeGetting access to Meetup groups and events that connect you with other SAFe® certified professionalsNote: SAFe® Meetups provides opportunities to the SAFe® certified across the globe. SAFe® Meetups allows to connect with each other face-to-face, share best practices (sometimes SAFe® experts attend or speak in these sessions to enable learning), and gain knowledge on Scaled Agile Framework in a local setting.Getting access to a variety of learning resources to support you during your SAFe® journey.Summing It UpFor professionals who are looking for career development in the Agile field, SAFe® certification can be the most relevant option today. It gives a guarantee to the companies that they hire individuals with the skills required to scale Agile and a strong knowledge of the SAFe® environment. On top of that, it is important to know that a large majority of big enterprises have implemented SAFe® and that the hunt for SAFe® certified professionals is still very active.
Rated 4.5/5 based on 1 customer reviews
8702
A Journey Towards Earning a Leading Safe® 4.6 Cer...

Our blog regularly provides insights about the Sca... Read More