Search

Best Ways To Split User Stories For Efficient Product Backlog Refinement

Product Backlog and User Stories: Product Backlog is an essential artefact of Scrum Framework. It comprises of a list of items (referred as PBI) that are planned to be implemented in the future. PBIs are generally in the form User Stories. A user story is the concise representation of a functional or technical requirement of a system. Writing appropriate user stories forms a strong base for achieving the sprint goals successfully and progressing towards the product vision eventually. "If you want to know more about a 'user story' you may also watch“ INVEST  The attributes of a well formed user story goes by the acronym INVEST, which was coined by Bill Wake in his book "Extreme Programming": Independent - Each story should be atomic and not dependent on any other stories Negotiable - Should have scope to allow negotiation between the scrum team and business team on the grounds of technical , functional  and budget constraints and modify itself accordingly Valuable - Must deliver some value to the stakeholders. If it is a functional user story, then there should be provide some business value , whereas technical user story should focus on architectural and non functional improvements. Estimable - Team should be able to arrive at a fair estimation for implementing the user story in terms of story points.  Small - Should be small enough to plan and implement within a sprint Testable - Should have a clear acceptance criteria , which gives the team all the necessary information to test every possible flow.   Product Backlog Refinement Product owners have to maintain a healthy backlog by frequently grooming the user stories in it. In the grooming sessions (Product Backlog Refinement), PO discusses with the team and work on improvising the poorly written user stories, breaking down the large user stories into manageable size, adding more clarity to the acceptance criteria , prioritizing the user stories and estimating them. As a Scrum Master, we should guide the team and PO in this backlog refinement activity by aiding them with the best practices in writing user stories of right size and prioritization. User Story Splitting Splitting user stories is a significant task in product backlog grooming. A user story should be neither too small nor too big. It has to be sized appropriately , in such a way that , the implementation of it could be decomposed into one or more tasks. All the tasks planned must be completed within a sprint. Generally , user stories of size more than 8 or 13 story points are split further. However this number may vary from one scrum team to another based on their capacity and velocity. Benefits of splitting a story: Smaller is always better. User stories of relatively less story points are  * Easy to understand and groom * Leads to accurate estimation * Results on quicker implementation * Aids thorough testing   Size of an user story is said to be optimal if it could be implemented within 0.5 day (half a day) to 10 days. Methods of splitting :  A user story can be split: Horizontally - through architectural tiers as one layer at a time Vertically - as functional pieces across all the layers at a time. The horizontal layers split accordingly can be further divided as tasks. A common metaphor used to differentiate both these methods is cutting a cake layer by layer ( horizontal) and portion by portion of all the layers (vertical). Only by tasting a portion of all the layers, one would be able to feel the essence of the entire cake. Same is the case with story splitting. Vertical (Functional) splitting is more valuable than the horizontal one. Advantages of vertical splitting: Dependencies and risks could be identified at an earlier stage Nice to have features can be segregated and deferred for later sprints Considerable progress can been seen on functional part every day, whereas in horizontal slicing no benefits are seen until all related stories are complete Leads to quicker testing and faster feedback loop - in horizontal , need to wait until all the dependent stories are done  Helps to prioritize based on incremental value Techniques for splitting stories vertically: User stories can be split vertically based on the following patterns: Generic Terms: If an user story has more generic terms, then there is a possibility to split it vertically.  For eg : As a library member, I want to search the availability of various kinds of books for children and share it with my network. Here, "various kinds" , "share it" are more generic terms. They provide a way to split the story incrementally as below : * Develop a UI that displays all the book categories when a registered library member login * Provide a search functionality to the member, where in results are also categorized such as "fiction for kids under 10", "fiction for kids 11-15" and so on * Enable to users to share the result via email, whatsapp etc Connectors : If the user story is represented using a compound sentence, then it is obvious that it can be split vertically. In such cases, look out for conjunctions in the user story like "and, or, as well as, when, if" and split it based on these connecting words or conjunctions like : and, or, if, when, but, as well as. Acceptance criteria:  Read out the acceptance criteria; if it is too complex and some parts of it can be pulled out and developed as an independent user story, follow the same. Eg:  As a senior associate  of the organization, I want to register for the in house training programs so that I can attend the trainings and upskill myself. Acceptance criteria :  All the senior associates must be informed about the training programs through mail. Senior associates should be able to submit their details through a form for registration. Mail confirmation must be sent on successful registration. In the above scenario, each of the criteria can be designated as a separate user story. Workflow steps:  Identify the workflows that connect different roles for a specific function, and if they can be completed independently split them as a separate user story. Eg: For an assignment approval system in a school, the following can be the possible user stories        As a student, I should be able to submit my assignments to the teacher for grading         As a teacher , I should be able to view the assignments submitted by the students        As a teacher, I should have the UI to request for more clarifications Apart from the above, below are the other patterns based on which user stories can be split vertically: Operations - Create, Read, Update, Delete operations required for a functionality Business Rules deviations Variations in Data given as input to the system Variations in User Interface Spikes - If there are many unknowns in a user story and it requires research for uncovering the grey areas, then create spikes to get the insights of the user story. Based on the spike's outcome, we can proceed with the implementation of actual user story. Best practices for story splitting: * Do not split the stories too early - split just in time, when it's priority for implementation is high. * Do not compromise quality / non functional requirements - NFRs must be taken into consideration while splitting. If having a choice between a couple of user story splitting strategies, prefer the one that will result in similarly sized sub-stories. — Wojciech Zawistowski (@velesin) May 29, 2015 * Ensure that there is no feature debt - splitting should not leave out any functionality without implementation. * Story splitting is not a task to be owned by the PO alone - Along with the Scrum Master, other team members also give their view on best possible ways to split the stories as they are the actual persons who are going to develop the stories into working functionalities.
Rated 4.0/5 based on 16 customer reviews
Best Ways To Split User Stories For Efficient Product Backlog Refinement 193
Best Ways To Split User Stories For Efficient Product Backlog Refinement

Product Backlog and User Stories:

Product Backlog is an essential artefact of Scrum Framework. It comprises of a list of items (referred as PBI) that are planned to be implemented in the future. PBIs are generally in the form User Stories.

A user story is the concise representation of a functional or technical requirement of a system. Writing appropriate user stories forms a strong base for achieving the sprint goals successfully and progressing towards the product vision eventually.

"If you want to know more about a 'user story' you may also watch“


INVEST 

The attributes of a well formed user story goes by the acronym INVEST, which was coined by Bill Wake in his book "Extreme Programming":

Independent - Each story should be atomic and not dependent on any other stories

Negotiable - Should have scope to allow negotiation between the scrum team and business team on the grounds of technical , functional  and budget constraints and modify itself accordingly

Valuable - Must deliver some value to the stakeholders. If it is a functional user story, then there should be provide some business value , whereas technical user story should focus on architectural and non functional improvements.

Estimable - Team should be able to arrive at a fair estimation for implementing the user story in terms of story points. 

Small - Should be small enough to plan and implement within a sprint

Testable - Should have a clear acceptance criteria , which gives the team all the necessary information to test every possible flow.
 

Product Backlog Refinement

Product owners have to maintain a healthy backlog by frequently grooming the user stories in it. In the grooming sessions (Product Backlog Refinement), PO discusses with the team and work on improvising the poorly written user stories, breaking down the large user stories into manageable size, adding more clarity to the acceptance criteria , prioritizing the user stories and estimating them.

As a Scrum Master, we should guide the team and PO in this backlog refinement activity by aiding them with the best practices in writing user stories of right size and prioritization.


User Story Splitting

Splitting user stories is a significant task in product backlog grooming. A user story should be neither too small nor too big. It has to be sized appropriately , in such a way that , the implementation of it could be decomposed into one or more tasks. All the tasks planned must be completed within a sprint.

Generally , user stories of size more than 8 or 13 story points are split further. However this number may vary from one scrum team to another based on their capacity and velocity.


Benefits of splitting a story:

Smaller is always better. User stories of relatively less story points are 

* Easy to understand and groom
* Leads to accurate estimation
* Results on quicker implementation
* Aids thorough testing  

Size of an user story is said to be optimal if it could be implemented within 0.5 day (half a day) to 10 days.


Methods of splitting : 

A user story can be split:

Horizontally - through architectural tiers as one layer at a time

Vertically - as functional pieces across all the layers at a time. The horizontal layers split accordingly can be further divided as tasks.

A common metaphor used to differentiate both these methods is cutting a cake layer by layer ( horizontal) and portion by portion of all the layers (vertical). Only by tasting a portion of all the layers, one would be able to feel the essence of the entire cake.

Same is the case with story splitting. Vertical (Functional) splitting is more valuable than the horizontal one.


Advantages of vertical splitting:

  • Dependencies and risks could be identified at an earlier stage
  • Nice to have features can be segregated and deferred for later sprints
  • Considerable progress can been seen on functional part every day, whereas in horizontal slicing no benefits are seen until all related stories are complete
  • Leads to quicker testing and faster feedback loop - in horizontal , need to wait until all the dependent stories are done 
  • Helps to prioritize based on incremental value

Techniques for splitting stories vertically:

User stories can be split vertically based on the following patterns:



Generic Terms:

If an user story has more generic terms, then there is a possibility to split it vertically. 
For eg : As a library member, I want to search the availability of various kinds of books for children and share it with my network.

Here, "various kinds" , "share it" are more generic terms. They provide a way to split the story incrementally as below :

* Develop a UI that displays all the book categories when a registered library member login
* Provide a search functionality to the member, where in results are also categorized such as "fiction for kids under 10", "fiction for kids 11-15" and so on
* Enable to users to share the result via email, whatsapp etc

Connectors :

If the user story is represented using a compound sentence, then it is obvious that it can be split vertically. In such cases, look out for conjunctions in the user story like "and, or, as well as, when, if" and split it based on these connecting words or conjunctions like : and, or, if, when, but, as well as.

Acceptance criteria: 

Read out the acceptance criteria; if it is too complex and some parts of it can be pulled out and developed as an independent user story, follow the same.
Eg:  As a senior associate  of the organization, I want to register for the in house training programs so that I can attend the trainings and upskill myself.

Acceptance criteria :  All the senior associates must be informed about the training programs through mail. Senior associates should be able to submit their details through a form for registration. Mail confirmation must be sent on successful registration. In the above scenario, each of the criteria can be designated as a separate user story.

Workflow steps: 
Identify the workflows that connect different roles for a specific function, and if they can be completed independently split them as a separate user story.

Eg: For an assignment approval system in a school, the following can be the possible user stories
       As a student, I should be able to submit my assignments to the teacher for grading 
       As a teacher , I should be able to view the assignments submitted by the students
       As a teacher, I should have the UI to request for more clarifications

Apart from the above, below are the other patterns based on which user stories can be split vertically:

  • Operations - Create, Read, Update, Delete operations required for a functionality
  • Business Rules deviations
  • Variations in Data given as input to the system
  • Variations in User Interface
  • Spikes - If there are many unknowns in a user story and it requires research for uncovering the grey areas, then create spikes to get the insights of the user story. Based on the spike's outcome, we can proceed with the implementation of actual user story.

Best practices for story splitting:

* Do not split the stories too early - split just in time, when it's priority for implementation is high.

* Do not compromise quality / non functional requirements - NFRs must be taken into consideration while splitting.


* Ensure that there is no feature debt - splitting should not leave out any functionality without implementation.

* Story splitting is not a task to be owned by the PO alone - Along with the Scrum Master, other team members also give their view on best possible ways to split the stories as they are the actual persons who are going to develop the stories into working functionalities.

Nidhya

Nidhya Palaniappan

Scrum Master | Agile Project Manager

Leave a Reply

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

Suggested Blogs

5 Reasons To Have Fixed-Length Sprints

Should the sprint length in Scrum be fixed or variable? It has been a hot topic of discussion for years but most of the experiences shared by Scrum Masters go in favour of fixed length sprints; and, I too follow the rule of fixed length sprints. According to Agile Cadences and Technical Debt Survey report, 68% Scrum Masters favoured fixed length sprints while 29% accepted to make infrequent changes in the sprint length. Only 7% Scrum Masters accepted to change sprint length frequently as and when required. No doubt, flexible sprint length releases work pressure on the members but this practice develops a number of undesired apparent or hidden snags pertaining to quality, cost, time and scope.  Here in this article, I will explore 5 more commonly accepted reasons to adopt fixed-length sprints framework.  1. Teams Benefits from a Regular Rhythm Regular time-boxed delivery is the core Scrum discipline; therefore, we can’t take the liberty to have flexible sprint lengths. In case of flexible sprint lengths, team members are unsure of schedule. The fixed duration sprint benefits the Scrum teams because each member has to be settled with a rhythm.   2. Sprint Planning Becomes Easier The fixed sprint length makes the sprint planning easier because the team members know how much work they are supposed to deliver in the forthcoming sprint.  3. Tracking Velocity Is Easier Tracking Scrum velocity is easier with same length sprints. You can’t be sure of completing twice the amount of work if the one-week sprint period is extended up to two weeks. The alternative practice may be to normalize the velocity on per-week basis, but it seems a needless and complex exercise if the Scrum sprints are kept at the same length.   4. On the Time Course Corrections It is very common to find a gap between the demand of the product manager and the amount of work delivered. Fixed-length sprints minimize that gap by bringing the product manager and engineers together at a fixed interval. The findings at each sprint guide the Scrum team to incorporate the required changes before the particular task is done, tested & documented.  5. Maximizes Responsiveness to Customer Fixed-length sprints improve the responsiveness to customer requests. True, instant turnaround to customer requests is not possible; yet, it can be addressed quickly at priority. The only way to satisfying the customer at the best is to deliver the new feature or to fix the bug quickly in short fixed-length sprint cycles.  How to Fix the Ideal Sprint Length – 5 Tips:   Ideally, sprint is a fixed time period of 1-4 weeks; it depends upon the team to schedule the sprint. The shorter Sprints spanned for one - two weeks help the Scrum teams identify the problems faster; but sometimes it seems uncomfortable. Many times, Scrum teams decide for the 3 - 4 weeks longer sprints to avoid indulgence towards these problems/ impediments; however, it is not a Scrum-like approach because Scrum principles guide to identify and deal with the problems at the earliest. So, the question is how to fix the ideal sprint length holding the balance between focus and opportunistic adaptiveness. The following 5 tips will help you optimize the sprints schedule:    1. Uncertainty may come in a variety of forms like not properly defined requirements, new technology, high-risk potential, difficult-to-implement interface etc. In case of significant uncertainty, you should go for shorter sprints - the most effective way to refine the project requirements or to try the new technology before getting set for solution development.  2. The volume of tasks and the expected time required affect the selection of sprint length. The team members should be comfortable to accomplish the task to complete a user story during the gap between the two sprints; and, as a Scrum Master, you should have a fair idea of the time required.     3. If you are facing a lot of disruptions, shorten the Sprint length to match the occurrence of disruptions.   4. The project duration is the key deciding factor for Scrum sprint duration. A short-period project such as one of three-month benefits from shorter sprints because of more reviews at shorter periods. If the project is long in duration, continue to look at the other factors. 5. Each Scrum sprint provides an opportunity to the Scrum Master to document the progress to stakeholders. Each sprint provides an opportunity to stakeholders to request for revisions. If you expect the stakeholders to provide input, prefer to set shorter periods for the sprints.   Setting your iterations too short in #scrum can have a damaging effect. "Failed" sprints and poor morale. #agile #teams — John Cutler (@johncutlefish) June 10, 2017 Concluding Thoughts:  Shorter Sprints are preferred because of many reasons as discussed above but these need to be scheduled perfectly at comfortable intervals so that the sprint planning, sprint reviewing, sprint retrospective can be meaningful. Instead of fixing the sprint length to fit the ‘Product Backlog Items’ size, it is better to make the items smaller. The Certifications like CSM and other project management training and courses provide the deep insights into the perfect sprint planning.  
Rated 4.0/5 based on 43 customer reviews
5 Reasons To Have Fixed-Length Sprints

Should the sprint length in Scrum be fixed or variable? It has been a ... Read More

5 Scrum Boards that perfectly depict project progress

Quite possibly, few tools are as simple – yet as powerful – as a Scrum task board. Teams that plan their work in sprints use these boards during each sprint to visually depict where they are at. Just by looking at the task board, it is possible to evaluate the progress and judge whether the sprint is on track or not. In its simplest form, a task board has a list of tasks that are categorized as yet-to-start, ongoing and completed. Over the years, Agile teams across the world have created their own adaptations of the traditional Scrum board….have a look, and decide which one will work for you! The Scrum wall                                    Photo credit: http://jalbum.net/blog/entry/getting-ready-to-launch-the-new-site Teams that use up the entire wall as a Scrum task board get extra space that can be put to good use. They can put down all their information in one place, with additional inputs like the overall calendar, backlog, decisions, comments and so on up there for everyone to see. Say it with Lego!                                                             Source: http://agilethings.nl/creative-planning/ We always knew Lego was versatile, but this gives the concept of versatility a whole new look! This team uses a Lego planning board, with rows depicting user stories and columns depicting weeks or sprints. Each team member is assigned one colour, and the numbers of bricks in that colour show the exact time availability of that member. A long 4 stud brick indicates a full day of work, while a two stud represents a half day. A fun and creative way to plan your sprints! Hourglass Scrum/Kanban board                                 Source: http://www.strongandagile.co.uk/index.php/the-hourglass-scrumban-board/ An hourglass is a fun way to depict the flow of tasks. Work in progress tasks are the ones at the neck of the hourglass; completed tasks are moved below and the pending ones are in the top half of the hourglass. Note that when the WIP tasks are limited to one in each story( as the space in the neck is narrow), they get more attention. Release Radar                                              Source: http://agileboardhacks.com/tag/portfolio-management/ By turning the traditional board into a circle, this team led by Daniel Aragao of Thoughtworks created a great way to deal with prioritising urgent tasks. Items in the outer rings of the circle are not urgently required, while those closer to the centre are needed asap. Each slice of the circle represents a project , which is identified by a sticky note on the outer edge. Scrum for Trello Teams that work in different locations and across various time zones need a virtual Scrum board to track work progress. Trello is often used to manage task boards and sprints, with a Firefox/Chrome extension called Scrum for Trello. Visit this link to learn more: http://scrumfortrello.com/   Innovation is the key to success. What works for another Scrum team may not work as well for you; try out your own tweaks and quirks, and customise your own Scrum task Board. You can learn more about Scrum tools and techniques by attending a CSM Training from a certified trainer. Happy Scrumming!
Rated 4.0/5 based on 20 customer reviews
5 Scrum Boards that perfectly depict project progr...

Quite possibly, few tools are as simple – yet as powerful – as a S... Read More

Is SAFe® 4.5 Certification Worth The Price?

In this decade where traditional methods for Project Development are on the verge of being obsolete, organisations are in dire need of Agile. Call for Agile experts has expanded in the IT business and is spreading to multiple areas of businesses also. This request triggers the requirement for certifications which enlisting organisations can manage an account with.These certifications range from the entry level to the advanced levels and are benefiting the software professionals in more ways than one. In the recent times, there has also been a need to upgrade Agile practices in organisations, and this, exactly, has given rise to the demand for scaled Agile. This has spurred the software professionals to take up Leading SAFe® certifications to enhance their career.This article will discuss the top Leading SAFe® 4.5 certifications and their career benefits.Benefits of the certificationGenerally speaking, certification will help you to get the following benefits-Better foresightBetter salaryBetter integrityKeeping pace with the current market approachTop 6 SAFe® 4.5 certifications1. Leading SAFe® 4.5 training (SAFe Agilist)SAFe® Agilist(SA) certification will help you to empower your organisation’s success. SA certification will allow you not only to execute and deliver value through Agile Release Trains but also to lead a Lean-Agile transformation in scaled organisations. This certification will also let you build a continuous delivery pipeline even in a DevOps culture. Also, the course exhibits the power of coordinating with the larger solutions and promoting a Lean portfolio culture within the enterprise.Learning Objectives:As a SAFe® Agilist (SA), you should be able to-Exhibit how the combination of Lean, Agile, and Product Development shapes the SAFe® foundation.Apply SAFe® principles to scale Lean and Agile development in the organizationFind out and apply a Lean-Agile Mindset and principles accordinglyConsistently discover, incorporate, deploy, and deliver valueEngage with a Lean portfolioHarmonising for the development of the larger solutionsImprove Lean-Agile leadership skillsBolster a Lean-Agile transfiguration in the enterpriseFinish the SA training and lead to the certification exam What will attendees get? 2-Day Instructor-Led Classroom Training16 PDUs and 16 SEUsCourseware authored by Scaled AcademyOne year membership with Scaled AgileFree downloadable reference materials from Scaled Agile FrameworkThe course is for:Executives and Leaders, Managers, Directors, CIOs, and VPsDevelopment, QA, and Infrastructure ManagementProgram and Project ManagersProduct and Product Line ManagementPortfolio Managers, PMO, and Process LeadsEnterprise, System, and Solution ArchitectsPrerequisites:The course is free for the desired attendees. But, following prerequisites are needed to attend the SAFe® Agilist (SA) exam-5+ years’ experience in software development, testing, business analysis, product, or project managementExperience in ScrumExam Details:Time-span: Candidates have 90 minutes (1.5 hours), commencement of the examNumber of Questions: 45Passing Score: 34 out of 45 (76% passing score)Certification:On clearing the certification exam, the candidates will receive-SAFe® 4.5 Agilist certificate1-year membership with the SAFe® Community Platform, which includes access to the SA Community of PracticeA variety of learning resources to support you during your SAFe® journey2. SAFe 4.5 for teams (SP)Today, SAFe® 4.5 certified practitioners are in huge demand for their ability to scale the Agile methodology within the enterprise. This course makes the team aware of the Scrum principles, Lean thinking tools, roles, and processes. New teams or Scrum teams seeking for the Agile adoption and scaling within the organization, will find this course much helpful. Learning Objectives:As a SAFe® Practitioner (SP), you should be able to-Demonstrate SAFe® Agile principles to the teamManage Agile teams on Agile Release TrainPlan sprint iterationsImplement iterations and deliver valueDevelop your teamCoordinate with other teams on the trainWhat will attendees get?16 PDUs and 16 SEUsFreely downloadable e-book100 Days’ Free Access to Agile and Scrum e-training The course is for:Team members who want to apply Lean and Agile principlesAll team members of an Agile Release Train (ART) preparing for the launchPrerequisites:The course is free for all attendees. But, following prerequisites are needed to attend the SAFe® Practitioner (SP) exam-Familiar with Agile principlesAware of Scrum, Kanban, and XPExperience in software and hardware development processesExam Details:Time-span: Candidates have 90 minutes (1.5 hours), once the exam has commencedNumber of Questions: 45Passing Score: 35 out of 45 (78% passing score)Certification:On clearing the certification exam, the candidates will receive-SAFe® 4.5 Practitioner (SP) certificate3. SAFe 4.5 Product Owner/Product Manager (POPM)The SAFe® 4.5 POPM certification is intended to make Product Owners/Product Managers aware of the SAFe® principles, Lean-Agile tools, Agile development practices and SAFe framework. Learning Objectives:As a SAFe® 4.5 (POPM), you should be able to-Implement SAFe® practices in the Lean enterpriseAttach SAFe® Lean-Agile principles and values to the PO/PM rolesCombine with Lean Portfolio ManagementImplement the Program Increment and deliver continuous valueCreate a PM/PM’s role action planWhat will attendees get? Training from a certified industry expertDownloadable courseware16 PDUs from PMI ® (PMI-ACP® / PMP® recertification)15 SEUs for CSPAttendee workbookMake you ready to attend the SAFe® 4 Product Owner/Product Manager (POPM) examOne-year membership to the SAFe® Community PlatformCourse completion certificateThe course is for:Product Managers, Product Line Managers, Product Owners, Business Owners, and Business AnalystsSolution Managers, Portfolio Managers, Program Managers, PMO personnel, and Process LeadsEnterprise, Solution, and System ArchitectsPrerequisites:The course is free to the desired attendees. But, following prerequisites are needed to attend the SAFe® 4.5 POPM exam.Leading SAFe® course attendeesWorking experience in the SAFe environmentExperience with Lean, Agile, or other relevant methodsExam Details:Time-span: Candidates have 90 minutes (1.5 hours), once the exam has commencedNumber of Questions: 45Passing Score: 35 out of 45 (78% passing score)Certification:On clearing the certification exam, the candidates will receive-SAFe® 4.5 Product Owner/Product Manager (POPM) certificate4. SAFe 4.5 Advanced Scrum Master (SASM) courseThe SAFe® 4.5 Advanced Scrum Master (SASM) certification equips the candidates with the skills that can be applied to lead high-performance Agile teams. Also, candidates will learn to apply DevOps practices and Kanban techniques and managing the interactions between the teams, stakeholders, and the Product Managers.Learning Objectives: As an SASM certified professional, you should be able to-Apply SAFe® principles in a multi-team environmentBuild a high-performing team and enable continuous improvementUnderstand Agile and Scrum anti-patternsFacilitate program planning, implementation, and value deliverySupport learning through participation in Communities of Practice and innovation cyclesWhat will attendees get? 16 PDUs and 16 SEUsFreely downloadable e-bookCourse completion certificateAttendee workbookOne-year membership to the SAFe® Community PlatformThe course is for:Existing Scrum MastersTeam leaders, project managers, and an Agile Team facilitator in a SAFeAgile coachesEngineering and development managers executing AgileAgile Program ManagersProspective SAFe® Release Train EngineersPrerequisites:The course is free for the attendees. But, having at least one or more of the following certifications is recommended to attend the SAFe 4.5 ASM exam-SAFe® 4 Scrum Master (SSM) certificationCertified Scrum Master (CSM) certificationProfessional Scrum Master (PSM) certificationExam Details:Time-span: Candidates have 120 minutes, once the exam has commencedNumber of Questions: 60Passing Score: 42 out of 60 (70% passing score)Certification:On clearing the certification exam, the candidates will receive-SAFe® 4.5 Advanced Scrum Master (SASM) certificate5. SAFe 4.5 Scrum Master with SSM certification trainingSAFe® 4.5 Scrum Master(SSM) certification will make you well-versed with the main components of the Scaled Agile Framework and allow you to lead high-performing Agile teams. This course will help you to improve quality of the products reducing time-to-market.Learning Objectives:As a SAFe® 4.5 Scrum Master with SSM certification training, you should be able to-Discuss Scrum practices in a SAFe® implementing enterpriseFacilitate Scrum eventsFacilitate effective Iteration executionAssist DevOps implementationSupport effective Program Increment executionSupport continuous improvementTrain Agile teams to maximize business resultsAssist DevOps implementationWhat will attendees get?Prepare and support to clear the exam16 PDUs and 16 SEUs (under the category C)Course completion certificateThe course is for:New Scrum MastersPresent Scrum Masters, who wish to assume new roles in the SAFe enterpriseTeam Leads who want to understand the Scrum Master roleSAFe® Release Train Engineers (RTEs) who want to coach for the role of the Scrum MastersPrerequisites:The course is free for the attendees. But, following prerequisites are a must to take the SAFe® 4.5 SSM exam-Familiarity with Agile principlesShould be aware of Scrum, Kanban, and eXtreme Programming (XP)Work experience in software and hardware development processesExam Details:Time-span: Candidates have 90 minutes (1.5 hours), once the exam has commencedNumber of Questions: 45Passing Score: 33 out of 45 (73% passing score)Certification:On clearing the certification exam, the candidates will receive-SAFe® 4.5 Scrum Master (SSM) certificate6. SAFe® 4.5 Release Train Engineer (RTE) certification courseSAFe® 4.5 RTE course will educate you on building the high-performing ART and understanding the role of  the RTE in a Lean-Agile transformation. Also, the attendees will learn to mentor the Agile leaders, teams and the Scrum Masters and how to prepare, plan and execute a Program Increment (PI).Learning Objectives: As a SAFe® 4.5 Scrum Master with SSM certification training, you should be able to-Apply Lean-Agile principles and tools to execute and deliver valueFostering continuous improvementConstruct a high-performing ART as a servant leader and coachPreparing an action plan to continue the learning journeyWhat will attendees get? Preparation and support for the SAFe® 4.5 Release Train Engineer (RTE) examCourse completion certificateOne-year membership to the SAFe® Community PlatformThe course is for:RTEs and Solution Train Engineers (STEs)Program and project managersScrum MastersLeaders and managersAgile coachesSAFe® Program Consultants (SPCs)Prerequisites:Following are the prerequisites required to attend the exam-Should have at least one current SAFe certificationHave launched or participated in at least one ART and one PIExam Details:Time-span: Candidates have 120 minutes to complete the examNumber of Questions: 60Passing Score: 40 out of 45 (67% passing score)Each retake attempt costs $250Certification:On clearing the certification exam, the candidates will receive-SAFe® 4.5 RTE certificateNote:For all the courses, the registration fee includes the first exam attempt if the exam is taken within 30 days of course completion. Each retake attempt costs $50.After any of these SAFe® 4.5 certifications, you will get a Digital badge to promote your accomplishment online.Summing It UpToday, the SAFe® 4.5 certification is considered as a standard for Lean-Agile endeavours. Over 70% of the US Fortune 100 companies are utilising SAFe and the call for the SAFe® certified experts is rising at an exponential rate. The competitors that are searching for the more prominent vocation ahead, can go for the Leading SAFe® 4.5 certifications, as many employers seek candidates with credentials that convey their capability to work inside a SAFe® environment (verified through a SAFe® certification).
Rated 4.0/5 based on 47 customer reviews
Is SAFe® 4.5 Certification Worth The Price?

In this decade where traditional methods for Project Development are o... Read More