Search

Learn Scrum with JIRA

Many organizations use JIRA as a one-shot solution to automate their processes, and JIRA has almost become synonymous with Agile. Even organizations that don’t deploy it across all levels use it for at least some of their projects. Such is the popularity of JIRA. So, what exactly makes it so popular? JIRA provides a simple and easy-to-use solution for project management tasks, right from gathering requirements to maintaining releases and generating all sorts of reports and metrics. The best part of the tool is that it is highly customizable, attending to the needs of one and all. If it is said that there isn’t a thing that one cannot do using JIRA in terms of project management, then that is not an understatement.  Since Agile is the buzzword now and most organizations are opting for it, this article will provide users with a detailed insight on how to carry out their project management tasks and software development activities by using a Scrum framework.   Before moving ahead, there are two basic pre-requisites that the user who intends to use JIRA must have and they are: Pre-Requisites:  An active account on JIRA Required permissions (Super Admin, Project Admin, etc. – Defined by organizations) 1. Creation of Project: The first and most important thing is to create a project in JIRA under which we will be carrying out our activities and tracking the progress of those. There are two ways a user can create a project.  Method 1:  Step 1: Log in to JIRA using your credentials. Once you are logged in, you will land on the project dashboard which will look something like this.  Step 2: Click on Settings icon and select the Projects option as highlighted in the image below.   Step 3: Select “Create Project” option as shown in the image.   Step 4: After clicking on “Create Project”, you will be prompted with two options to select from.  Classic Project  Next Gen Project Step 5: Once you have selected the type of project, you will be asked to enter the Project name. You will also have the option to change the type of template i.e Scrum, Kanban or Bug Fixing, depending on the purpose for which you wish to use JIRA.  Once done, you must click on the “Create” button.  And voila, it’s that simple. Once you have clicked on the create button, you will land on the project dashboard with the name of the project highlighted on the top left. As we can see in the image below, project name “My Scrum Project” is visible. Method 2.  The steps remain the same, only difference is that instead of navigating through settings, once you have logged in, you will have the option to navigate via “Projects” link as depicted in the pic.  2. Creating Backlog: Once the project has been created the second important step is to define requirements in a backlog. As you can see in the pic below, there is the option to select “Backlog” from the left side panel/navigation pane to navigate to the backlog section.  Here you can start creating backlog items. This backlog serves as the “Product Backlog”. Users can outline requirements in terms of Epics, User Stories, Tasks and Bugs which are known as “issue types” in JIRA. In short, everything that is created is an issue in JIRA. Please note that for ease of understanding and reference, I am sticking to the most basic issue types as mentioned above.  Step 1: To create issues in JIRA, all that is needed to be done is to click on the “Create” button on the top most navigation bar. This bar remains visible at all times by default, no matter whichever page you navigate to. Step 2: Once the user clicks on “Create”, a dialog box to enter details of the issue will open.   The two most important fields in this are:  Project: This field, by default, is populated with the name of the project you are in. But in case you wish to change the project field, the same can be selected from the dropdownIssue Type: This option by default is selected as “Story” but can be changed depending on which issue you want to create. The relevant issue can be chosen from the dropdown. Below image shows how it all looks like in JIRA. There are two types of fields on the dialog box; Mandatory and Non-Mandatory. Mandatory fields are marked with a red Asterix. Also, these fields change on change of the issue type i.e. on basis of what is applicable to the issue type being selected.  As already mentioned, JIRA is highly customizable and a JIRA admin can add or change more issue types based on what terminology is being used by the project and/or organization on the whole. E.g. Issue type of Features can also be added in case teams follow a feature-based development approach wherein features are divided across teams and encompass the hierarchy of epics and stories.  In a similar manner, issue type “Story” can be amended to be displayed as “User Story” or at times to be more specific, something like “Functional User story” and/or “Technical User story”. In addition to this, the fields are also customizable. New fields can be added and the rule of mandatory and option field can also be altered depending on what works best for the team. To make these changes, the JIRA admin needs to navigate to the settings section and then to the desired settings type to change them. Please note that these settings will only be available to the user who either is a JIRA admin or has permission to perform these activities. Permissions are issued by the JIRA admin to the user.  Coming back to the topic of creation of backlog, once you fill up the details and click on “Create” at the bottom of the dialog box, a new issue is created in JIRA that now starts reflecting in the backlog.  Issues can also be created by using the short cut link available in the backlog section as highlighted below.  Once you click on “+” icon, you will be able to select the type of issue to create and provide a summary for the same.   After entering the summary details, you are required to click enter and the issue is created. To enter other details, you will have to navigate to the created issue by clicking on it in backlog or opening the same in a new tab and then doing the needful.  As soon as an issue is created, the same starts reflecting in the backlog. Here you can see two stories and one bug that were created, are visible in the backlog. 1. Linking Issues:  We all know the hierarchy of requirements goes something like Epics > Stories > Tasks. JIRA gives us the capability to link one issue type with another. To start with as a very basic ask, stories will fall under the epics and thus need to be linked with the correct epic. This linkage is something which replaces the requirement traceability of traditional models. When everything is perfectly linked then it can be easily known which requirement from the customer was covered under which epic and if we go into a granular level, under which story and even tasks the requirements fall under. Similarly, if a bug is found in the story while working on it, the bug can also be logged and linked against the story.  To link issues, the steps below can be performed.  Epic Link: To link stories under an epic, JIRA specifically provides the field “Epic Link” in stories. The field at most times is made mandatory by organizations to make sure that every story that is created in JIRA is by default linked to the epics. Here the epic becomes the parent issue of the story and thus it also becomes easy to make sure that every requirement has been worked upon.  Step 1: There are two ways to create the Epic link. While creation of the story, you will have the option to mention Epic link or if the story is created using shortcut link, the same can be added by opening the story and then mentioning the epic in the epic link field as shown below. Step 2: Once selected the same starts reflecting in the story details.   Step 3: To see the linkage, you need to navigate back to backlog. The link starts displaying in the backlog.   2. Linking Bugs:  Once the bugs are created, they can be used to block user stories in a similar fashion, though there is no specific field like epic link in case of bugs, they can be linked using the “Link issue” option.  Step 1: Once the bug is created, note the issue ID and open the story which needs to be blocked and select the “Link Issue” option.  Step 2: By default, “is blocked by” option is selected, indicating that the story is blocked due to the following issue. As soon as you enter the bug issue id and click on link, the story is linked with the bug or to be more specific, the story is marked ‘blocked’ by the bug. In this way multiple stories can be blocked with a single bug and vice versa.   Note – Stories can be linked to other stories to showcase linkage, to mark dependency, to display duplicity/redundancy etc in the same manner, all that is needed is to select the correct option from the dropdown after selecting “Link issue”. Issue Prioritization in Backlog.  As the rule goes, the product backlog must be prioritized at all times i.e. the issue with the highest priority should be at the top and the issue with least priority should be at the bottom of the backlog, so that the teams working on the backlog have a clear idea about the work they need to pull in once the next iteration starts or to understand if they have capacity for more during the ongoing sprint. Keeping the backlog prioritized also helps the team to keep working as per the product roadmap in the absence of the product owner and as such the team does not get blocked.  JIRA also provides the capability to keep the backlog prioritized at all times by the simple function of dragging and dropping the issue above or below the other ones. Below images will give you an idea of the same.  Scenario 1: Once you start creating issues in the backlog, the issues start reflecting in the ascending order of their Issue IDs i.e. the order in which they are created. For ease of reference, the issues have been named as 1, 2, 3, 4 and placed one after the other.  Now assume that the priority of Story 4 is the highest and thus it should be at the top of the backlog, followed by test story 2, followed by 1 and 3 respectively. Thus, they should be placed in order of 4,2,1 and 3 in the backlog. This can be done by simply dragging the items to bring them in the desired order.  Scenario 2: Below image gives you a backlog which is sorted on the basis of prioritization of stories as per the priority defined by the PO. Bugs too can be dragged and placed at the relevant position in the backlog depending on their severity and priority. All these activities of creation and prioritization of backlog are done primarily by the PO. In case the PO is supporting multiple teams and there are BAs supporting individual teams or acting as proxy POs for the teams, then POs can leverage them for backlog management. Scrum master needs to ensure that the backlog is prioritized, properly detailed and at least the stories for the immediate next sprint remain in a ready state.   3. Creating & Starting a Sprint:  Once the backlog has been created, the next step for the team is to gather and hold the sprint planning event. PO can open the stories and discuss the details and Acceptance Criteria with team members. Once all the stories have been discussed, the team can start pulling the stories in the sprint and for that to happen the team will need a sprint in JIRA. It is again very simple.  Step 1: In the backlog section, there is a “Create Sprint” button.  Step 2: Once you click on the button; a sprint is created, starting from sprint 1 with a prefix of project ID as shown in the image below. You have the option to create issues directly in the sprint using the quick link as mentioned above for the backlog or the issues can be dragged and dropped in the sprint created. All the issues dragged and dropped in the sprint created, as discussed in sprint planning, will serve as the sprint backlog.  Step 3:  Once all the issues are dragged and dropped in the sprint, the sprint is ready to be started. As an example, we see that test story 4 and 2 as well as a bug have been dragged to sprint 1 as displayed in the image below.Please note as part of sprint planning session, details like Story Assignee, story points and hourly estimates can be filled in the stories using the fields available. Also, in case the story owner wants to highlight the individual tasks they intend to perform as part of working on the story like Analysis, Coding, Review etc or in case multiple team members are working on a single story then to highlight individual work assignments, the option of creating tasks can be used. Tasks can be created just like stories, as mentioned above. It is similar to work breakdown in traditional models.What needs to be made sure is that before marking the sprint planning as being complete, all the stories have been pulled in sprint and assigned and estimated in terms of story points or hours or both, according to the approach the teams have decided to take. All the sub tasks that have been created, can optionally be assigned. If desired, these subtasks can also be estimated. Once all this is done, the Scrum Master can then mark sprint planning as complete and proceed to start the sprint.  As we know that before sprint planning, a goal is provided by the PO to the team. The same goal can be added in the sprint. Just select the three dots option besides the sprint on right side and select edit sprint and you will be able to enter the sprint goal.  4. Starting Sprint: Once the planning is complete and activities like estimations, assignments and tasking have been done, it is time to start the sprint. This is simple to do. In the backlog, there is a “Start Sprint” button. Once you click on it, a dialog box appears where you can verify sprint goal and set a duration for the sprint. After reviewing the details, you can click on “Start” and we are good to go.  5. in Progress:  Once the sprint has started, you can navigate to the “Active Sprint” section to visualize the progress on the stories in the sprint. Team members can update the stories to depict statuses from “To Do”, “In Progress” and “Done” and also update their daily hours in the stories in case teams are estimating in terms of hours.  6. Completing/Closing Sprint:  On the last day of the sprint, it is important to mark the ongoing sprint as closed in JIRA so that next sprint can be planned and started.  All the items which are marked done are considered complete. Anything pending to be completed is either moved to the next sprint or to backlog in consultation with the PO.  Step 1: In the “Active Sprint” section. On the top right corner, you need to click on “Complete Sprint” button.  Step 2: Once the “Complete Sprint” button is clicked, a dialog box appears with details of issues that have been completed and the ones which are pending. Select the place where you wish to move the pending items to, either to the backlog or next sprint which is to be started.Step 3: Once you select the desired value under “Move to” field and click on “Complete” button the Sprint is marked as complete.   

Learn Scrum with JIRA

6K
  • by Deepti Sinha
  • 16th Dec, 2020
  • Last updated on 19th Jan, 2021
  • 9 mins read
Learn Scrum with JIRA

Many organizations use JIRA as a one-shot solution to automate their processes, and JIRA has almost become synonymous with Agile. Even organizations that don’t deploy it across all levels use it for at least some of their projects. Such is the popularity of JIRASo, what exactly makes it so popularJIRA provides a simple and easy-to-use solution for project management tasks, right from gathering requirements to maintaining releases and generating all sorts of reports and metrics. The best part of the tool is that it is highly customizable, attending to the needs of one and all. If it is said that there isn’t a thing that one cannot do using JIRA in terms of project management, then that is not an understatement.  

Since Agile is the buzzword now and most organizations are opting for it, this article will provide users with detailed insight on how to carry out their project management tasks and software development activities by using a Scrum framework  

Before moving ahead, there are two basic pre-requisites that the user who intends to use JIRA must have and they are: 

Pre-Requisites:  

  • An active account on JIRA 
  • Required permissions (Super Admin, Project Admin, etc. – Defined by organizations) 

1. Creation of Project: 

The first and most important thing is to create a project in JIRA under which we will be carrying out our activities and tracking the progress of those. There are two ways a user can create a project.  

Method 1:  

Step 1: Log in to JIRA using your credentials. Once you are logged inyou will land on the project dashboard which will look something like this.  

Step 2: Click on Settings icon and select the Projects option as highlighted in the image below.   

Step 3: Select “Create Project” option as shown in the image.   

Step 4: After clicking on “Create Project”, you will be prompted with two options to select from.  

  • Classic Project  
  • Next Gen Project 

Step 5: Once you have selected the type of project, you will be asked to enter the Project name. You will also have the option to change the type of template i.e Scrum, Kanban or Bug Fixing, depending on the purpose for which you wish to use JIRA.  Once done, you must click on the “Create” button.  

And voila, it’s that simple. Once you have clicked on the create button, you will land on the project dashboard with the name of the project highlighted on the top left. As we can see in the image below, project name “My Scrum Project” is visible. Method 2.  

The steps remain the same, only difference is that instead of navigating through settings, once you have logged in, you will have the option to navigate via “Projects” link as depicted in the pic.

  

2. Creating Backlog: 

Once the project has been created the second important step is to define requirements in backlog. As you can see in the pic below, there is the option to select “Backlog” from the left side panel/navigation pane to navigate to the backlog section.  

Here you can start creating backlog items. This backlog serves as the “Product Backlog”. Users can outline requirements in terms of Epics, User Stories, Tasks and Bugs which are known as “issue types” in JIRA. In short, everything that is created is an issue in JIRA. Please note that for ease of understanding and reference, I am sticking to the most basic issue types as mentioned above.  

Step 1: To create issues in JIRA, all that is needed to be done is to click on the “Create” button on the top most navigation bar. This bar remains visible at all times by default, no matter whichever page you navigate to. Step 2: Once the user clicks on “Create”, a dialog box to enter details of the issue will open.   

The two most important fields in this are:  

  • ProjectThis field, by default, is populated with the name of the project you are in. But in case you wish to change the project field, the same can be selected from the dropdown

  • Issue Type: This option by default is selected as “Story” but can be changed depending on which issue you want to create. The relevant issue can be chosen from the dropdown. Below image shows how it all looks like in JIRA. 

There are two types of fields on the dialog box; Mandatory and Non-Mandatory. Mandatory fields are marked with a red Asterix. Also, these fields change on change of the issue type i.e. on basis of what is applicable to the issue type being selected.  

As already mentioned, JIRA is highly customizable and a JIRA admin can add or change more issue types based on what terminology is being used by the project and/or organization on the whole. E.g. Issue type of Features can also be added in case teams follow a feature-based development approach wherein features are divided across teams and encompass the hierarchy of epics and stories.  

In a similar manner, issue type “Story” can be amended to be displayed as “User Story” or at times to be more specific, something like “Functional User story” and/or “Technical User story”. 

In addition to this, the fields are also customizable. New fields can be added and the rule of mandatory and option field can also be altered depending on what works best for the team. 

To make these changes, the JIRA admin needs to navigate to the settings section and then to the desired settings type to change them. Please note that these settings will only be available to the user who either is a JIRA admin or has permission to perform these activities. Permissions are issued by the JIRA admin to the user.  

Coming back to the topic of creation of backlog, once you fill up the details and click on “Create” at the bottom of the dialog box, a new issue is created in JIRA that now starts reflecting in the backlog.  

Issues can also be created by using the short cut link available in the backlog section as highlighted below.  

Once you click on “+” iconyou will be able to select the type of issue to create and provide a summary for the same.   

After entering the summary details, you are required to click enter and the issue is created. To enter other details, you will have to navigate to the created issue by clicking on it in backlog or opening the same in new tab and then doing the needful.  

As soon as an issue is created, the same starts reflecting in the backlog. Here you can see two stories and one bug that were created, are visible in the backlog. 

1. Linking Issues:  

We all know the hierarchy of requirements goes something like Epics > Stories > Tasks. JIRA gives us the capability to link one issue type with another. To start with as a very basic ask, stories will fall under the epics and thus need to be linked with the correct epic. This linkage is something which replaces the requirement traceability of traditional models. When everything is perfectly linked then it can be easily known which requirement from the customer was covered under which epic and if we ginto a granular level, under which story and even tasks the requirements fall under. Similarly, if a bug is found in the story while working on it, the bug can also be logged and linked against the story.  

To link issues, the steps below can be performed.  

Epic Link: To link stories under an epic, JIRA specifically provides the field “Epic Link” in stories. The field at most times is made mandatory by organizations to make sure that every story that is created in JIRA is by default linked to the epics. Here the epic becomes the parent issue of the story and thus it also becomes easy to make sure that every requirement has been worked upon.  

Step 1: There are two ways to create the Epic link. While creation of the storyyou will have the option to mention Epic link or if the story is created using shortcut link, the same can be added by opening the story and then mentioning the epic in the epic link field as shown below. 

Step 2: Once selected the same starts reflecting in the story details.   

Step 3: To see the linkage, you need to navigate back to backlog. The link starts displaying in the backlog.   

2. Linking Bugs:  

Once the bugs are created, they can be used to block user stories in a similar fashion, though there is no specific field like epic link in case of bugs, they can be linked using the “Link issue” option.  

Step 1: Once the bug is created, note the issue ID and open the story which needs to be blocked and select the “Link Issue” option.  Step 2: By default, “is blocked by” option is selected, indicating that the story is blocked due to the following issue. As soon as you enter the bug issue id and click on link, the story is linked with the bug or to be more specific, the story is marked blocked by the bug. In this way multiple stories can be blocked with a single bug and vice versa.   

Note – Stories can be linked to other stories to showcase linkage, to mark dependency, to display duplicity/redundancy etc in the same manner, all that is needed is to select the correct option from the dropdown after selecting “Link issue”. 

Issue Prioritization in Backlog.  

As the rule goes, the product backlog must be prioritized at all times i.e. the issue with the highest priority should be at the top and the issue with least priority should be at the bottom of the backlog, so that the teams working on the backlog have a clear idea about the work they need to pull in once the next iteration starts or to understand if they have capacity for more during the ongoing sprint. Keeping the backlog prioritized also helps the team to keep working as per the product roadmap in the absence of the product owner and as such the team does not get blocked.  

JIRA also provides the capability to keep the backlog prioritized at all times by the simple function of dragging and dropping the issue above or below the other ones. Below images will give you an idea of the same.  

Scenario 1: Once you start creating issues in the backlog, the issues start reflecting in the ascending order of their Issue IDs i.e. the order in which they are created. For ease of reference, the issues have been named as 1, 2, 3, 4 and placed one after the other.  

Now assume that the priority of Story 4 is the highest and thus it should be at the top of the backlog, followed by test story 2, followed by 1 and 3 respectively. Thus, they should be placed in order of 4,2,1 and 3 in the backlog. This can be done by simply dragging the items to bring them in the desired order.  

Scenario 2: Below image gives you a backlog which is sorted on the basis of prioritization of stories as per the priority defined by the PO. 

Bugs too can be dragged and placed at the relevant position in the backlog depending on their severity and priority. All these activities of creation and prioritization of backlog are done primarily by the PO. In case the PO is supporting multiple teams and there are BAs supporting individual teams or acting as proxy POs for the teams, then POs can leverage them for backlog management. Scrum master needs to ensure that the backlog is prioritized, properly detailed and at least the stories for the immediate next sprint remain in a ready state.   

3. Creating & Starting Sprint:  

Once the backlog has been created, the next step for the team is to gather and hold the sprint planning event. PO can open the stories and discuss the details and Acceptance Criteria with team members. Once all the stories have been discussed, the team can start pulling the stories in the sprint and for that to happen the team will need a sprint in JIRA. It is again very simple.  

Step 1: In the backlog section, there is a “Create Sprint” button.  Step 2: Once you click on the button; a sprint is created, starting from sprint 1 with a prefix of project ID as shown in the image below. You have the option to create issues directly in the sprint using the quick link as mentioned above for the backlog or the issues can be dragged and dropped in the sprint created. All the issues dragged and dropped in the sprint created, as discussed in sprint planning, will serve as the sprint backlog.  

Step 3:  Once all the issues are dragged and dropped in the sprint, the sprint is ready to be started. As an example, we see that test story 4 and 2 as well as a bug have been dragged to sprint 1 as displayed in the image below.

Please note as part of sprint planning session, details like Story Assignee, story points and hourly estimates can be filled in the stories using the fields available. Also, in case the story owner wants to highlight the individual tasks they intend to perform as part of working on the story like Analysis, Coding, Review etc or in case multiple team members are working on a single story then to highlight individual work assignments, the option of creating tasks can be used. Tasks can be created just like stories, as mentioned above. It is similar to work breakdown in traditional models.

What needs to be made sure is that before marking the sprint planning as being complete, all the stories have been pulled in sprint and assigned and estimated in terms of story points or hours or both, according to the approach the teams have decided to take. All the sub tasks that have been created, can optionally be assigned. If desired, these subtasks can also be estimated. Once all this is done, the Scrum Master can then mark sprint planning as complete and proceed to start the sprint.  

As we know that before sprint planning, a goal is provided by the PO to the team. The same goal can be added in the sprint. Just select the three dots option besides the sprint on right side and select edit sprint and you will be able to enter the sprint goal.  

4. Starting Sprint: 

Once the planning is complete and activities like estimations, assignments and tasking have been done, it is time to start the sprint. This is simple to do. In the backlog, there is a “Start Sprint” button. Once you click on it, a dialog box appears where you can verify sprint goal and set a duration for the sprint. After reviewing the details, you can click on “Start” and we are good to go.  

5. in Progress:  

Once the sprint has started, you can navigate to the “Active Sprint” section to visualize the progress on the stories in the sprint. Team members can update the stories to depict statuses from “To Do”, “In Progress” and “Done” and also update their daily hours in the stories in case teams are estimating in terms of hours.  

6. Completing/Closing Sprint:  

On the last day of the sprint, it is important to mark the ongoing sprint as closed in JIRA so that next sprint can be planned and started.  

All the items which are marked done are considered complete. Anything pending to be completed is either moved to the next sprint or to backlog in consultation with the PO.  

Step 1: In the “Active Sprint” section. On the top right corner, you need to click on “Complete Sprint” button.  

Step 2: Once the “Complete Sprint” button is clicked, a dialog box appears with details of issues that have been completed and the ones which are pending. Select the place where you wish to move the pending items to, either to the backlog or next sprint which is to be started.Step 3: Once you select the desired value under “Move to” field and click on “Complete” button the Sprint is marked as complete.   

Deepti

Deepti Sinha

Blog Author

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

Join the Discussion

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

Suggested Blogs

12 Principles Behind the Agile Manifesto

Long before Agile came into existence, almost everything was done by the waterfall method. Its rigidity ensured that projects were easy to manage, but that also translated to more time to actually get a product deployed. So, it often happened that by the time the end product was ready to be deployed, the business requirements would have changed, thus making the product redundant. By the start of the millennium, markets had become more volatile, requirements were changing rapidly, and customers wanted quick fixes and accommodation of their changing needs.  That’s when 17 engineers got together and decided to come up with a new approach to software development that would address these problems. They came up with principles and values that would guide iterative software development. This document came to be known as the Agile Manifesto.  The authors of the Agile Manifesto came out with 4 values and 12 principles in order to help the professionals understand it easily and put it into practice. The manifesto created an impact and changed the future of project management. AGILE ESSENTIALS ESSENTIALS INTRODUCTION Agile Essentials is a set of resources intended to bring you up to speed on the concepts and principles of Agile. The Agile Essentials provide an overview of Agile values, principles, concepts, vocabulary, terms and roles to provide an understanding of the breadth of Agile and how it differs from traditional project management practices. AGILE 101:  Agile Development is a set of methods, principles and practices where solutions are integrated through the collaboration of self-organizing, cross-functional Development teams.  Agile methods, values and principles provide guidance on how to create and respond to change, deal with uncertainty and ultimately succeed in an uncertain and tumultuous environment. AGILE MANIFESTO The Agile Manifesto is a brief document built on 4 values and 12 principles for agile software development.  It was the work of 17 software development practitioners and was published in February 2001 to address the increasing need for an alternative to heavyweight software development processes. AGILE GLOSSARY Agile teams have created their own agile terminology to manage all these principles and practices. The glossary consists of 50 Agile Terms. Reference: Check URL https://www.agilealliance.org/agile101/agile-glossary/ for the list of agile terminologies. THE 12 PRINCIPLES The Agile Manifesto drafts out 12 principles for agile development practices. These 12 principles highlight on continuous delivery of valuable software in sprints and attention to technical excellence. The continuous delivery will involve quick feedback from the customer which will help reduce changes at the last minute. THE SUBWAY MAP The Agile subway map is a list of Agile practices grouped under different categories.  It helps to map out a specific practice that could help a team solve its problems.  The below picture depicts practices that are interconnected, while the colors at the bottom indicate each category. HISTORY OF THE AGILE MANIFESTO The vital value of agile development is that it should deliver value faster, ensure quality and certainty, and offer greater aptitude to respond to changes that correspond to market expectations. At a time when industries were growing rapidly and market expectations were changing, software needs and expectations were also changing and becoming more demanding. Agile software development history dates back to when the Agile Manifesto was created and Agile came into existence. In early 2001, a group of 17 developers held the (now famous) two meetings -- the first in Oregon and the second in Snowbird, Utah -- to discuss issues and solutions to overcome existing software development methodologies that were making it difficult to respond quickly to change.  The group comprised of 17 individuals, including Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas. All scenarios led to propose a working session. The working session organized by Dave, Robert and Jim had two objectives. Each person in the meeting will present to the group his lightweight method approach to build any complex software. Discuss the flow of heavyweight methods and how to address the complexities arising in the project development life cycle.THE FOUR VALUES OF THE AGILE MANIFESTO The Agile Manifesto thus tabled has 4 foundational values and 12 supporting principles. These values and principles lead to the agile approach to software development.  Agile methodology applies 4 values in different ways and these values guide the development and delivery of high-quality, working software. The four Agile Manifesto values are as follows: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Respond to change over following a plan INDIVIDUALS AND INTERACTIONS OVER PROCESSES AND TOOLS The Agile Manifesto values people higher than processes or tools because it is the people who respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs. In case of individuals, communication flows and happens when a need arises. In the case of process, communication is designed and requires specific content. WORKING SOFTWARE OVER COMPREHENSIVE DOCUMENTATION Historically, a mammoth amount of time was spent on documenting the product for development and delivery. Technical specifications, requirements, prospectus, test plans, documentation plans, and interface design were the documents that were created which required lots of time. This mammoth list caused long delays in development. Agile does not eliminate documentation, but provides all the information that is required for the developer to complete the work without getting bogged down in finer points. CUSTOMER COLLABORATION OVER CONTRACT NEGOTIATION  Customers are involved in all the agile phases of the project. There is total transparency. The Traditional methodologies have customers negotiate before the project starts and the project ends. This results in wastage of both time and resources. In the agile development process customers are kept in the loop and information is provided to all stakeholders by the product owner; this ensures that the final product meets all the requirements as per the expectations of the client. RESPOND TO CHANGE OVER FOLLOWING A PLAN Changes should be avoided in Traditional software development as they are considered to be expensive. The intention was to develop elaborate plans, with a well-defined set of features. Higher priority features are developed first and the rest follow. Delivering in the order as prioritized by the product owner will help the team work on itemized sprints. With Agile, the iteration means priorities can be shifted from iteration to iteration and new features can be added into the next iteration as required. Agile accepts changes as they are ways to improve a project/product. THE TWELVE AGILE MANIFESTO PRINCIPLES The Twelve Agile Manifesto Principles are the guiding principles that are included under the title “The Agile Movement”. Agile Manifesto architecture demonstrates the movement’s intent as described by Alistair Cockburn, one of the signatories to the Agile Manifesto, which is to bring development into alignment with business needs. The twelve principles of agile development include: CUSTOMER SATISFACTION THROUGH EARLY AND CONTINUOUS SOFTWARE DELIVERY: Customers will be happy when the software is delivered early for testing and feedback and when they are kept in the loop about the progress, the implementations, and product developers acknowledge the delivery value by fulfilling their top priority requirements first. A completed Iteration has an outcome, a working code to respond to the ever-changing user requirements. ACCOMMODATE CHANGES EVEN LATE IN DEVELOPMENT: Agile methodology stresses on responding to change instead of staying strictly aligned to an approved plan as was the case in the traditional methodology. It is a simplified version of handling changes with no formal documentation or approval. The changes are integrated for the customer’s competitive advantage because it takes care of the market changes in the business to bolster your advantage to emerging opportunities. DELIVERING WORKING SOFTWARE FREQUENTLY: Provide immediate value to the customers by delivering features that are done. The development teams are wholly responsible for completion of sprints. They ensure that each feature developed is tested, and matches the customer’s requirements before it is delivered. The project team needs to focus on the delivery of value to the customer within a fixed delivery timeframe. BUSINESS PEOPLE AND DEVELOPERS WORK TOGETHER DAILY : Agile accepts changes in software development. It is hence important to clarify requirements on a timely basis to always keep all the team members notified and up-to-date during the development of the software. SUPPORT, TRUST AND MOTIVATE TEAM: Agile depends on focused, trusted, and motivated individuals to complete projects as per requirements of the client. Development teams have all the power to select the work they are most interested in by self-organization with no interference from the external management. FACE-TO-FACE CONVERSATION WITH DEVELOPMENT TEAM: Feedback via face-to-face interaction or video conference with development teams in different geographical locations is always encouraged as it assists in easy and smooth transfer of information amongst the members. WORKING SOFTWARE IS THE PRIMARY MEASURE OF PROGRESS: The only way to measure success factors is by delivering a working product that satisfies the customer’s needs. Delivering functional software to the customer is the ultimate way by which progress can be measured. AGILE PROCESSES TO SUPPORT A CONSISTENT DEVELOPMENT PACE: Teams establish the velocity rate at which they can deliver working software, and they follow the same process with each release. Agile methodology aims to keep the work-life balance of development teams and never burden them with huge amount of work, thus keeping them happy and motivated.  ATTENTION TO TECHNICAL EXCELLENCE AND DESIGN: The right technical skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain market changes. SIMPLICITY: Focus on things that are important to add value to the project and customers. Develop the product as required and get the job done correctly. SELF-ORGANIZING TEAM ENCOURAGES GOOD ARCHITECTURE, REQUIREMENTS AND DESIGNS: In Scrum methodology, the team has overall control and is responsible for completing each sprint. The team performs in the best possible way needed to carry out the task. There is no interference of the project manager or from the human resources department. REGULAR REFLECTIONS ON HOW TO BECOME MORE EFFECTIVE: Self-improvement, process improvement, enhancing skills, and techniques help team members work more efficiently. It is imperative for Scrum teams to work and focus as a cognitive unit.  Working out new plans, checking requirements and adapting to changes will help the Scrum team to work more efficiently. THE GREAT AGILE DEBATE Agile development is a method based on iterative and incremental development. The requirements and solutions evolve in short sprint iterations through collaboration within self-organizing, cross-functional teams. The idea of the Agile method is to create a working software, compliant to change, and incorporate Face to Face interactions and collaboration over processes, tools or plans. It’s based on the principle of incremental delivery of the business value as quickly as possible through iterative development of software. The Agile Manifesto is the basis of the Agile practices, processes and principles etc used today. AGILE STRENGTHS:  It breaks tasks into small increments to allow the project to adapt and change quickly with the markets or client’s needs A project is developed in short iterations, or short time frames lasting from one to four weeks.  At the end of each iteration the agile approach allows teams to demonstrate the progress of the project to stakeholders; this ends the risk of bugs. Moreover, changes and additions can easily be adapted in each increment; this closely meets the client’s expectations. THE AGILE INDUSTRIAL COMPLEX The Agile community is now the Agile Industrial Complex.  It is that web of agile institutions, Agile thought leaders and Agile consulting firms that implicitly collude to make normal the very harmful and disrespectful imposition of Agile practices on teams without consent.  According to Martin Fowler agile had become mainstream in 2016. It is no longer exotic or frowned upon on, as in the early days. Growing agile industrial complex scenario: Organizations have spun the simple agile methodologies into complex industrial processes. This complex agile industrial has ballooned up and further used only for commercialization purposes. The agile-industrial complex trains people provide shiny certificates and pushes those people into consulting or managing positions. Focus on methodology: Every organization today focuses on agile methodologies for creating different products. This has resulted in the implementation of agile methodologies in organizations without any technical excellence of able and experienced engineers.  Focus on projects instead of products: Instead of connecting development team with clients and focusing on quality, the deadline and finishing of the project is prized or is given more importance. IS THE MANIFESTO STILL RELEVANT? The Agile Manifesto has made a profound effect on software development, even reaching beyond into the wider world of business. There’s ample evidence that the Agile Manifesto remains relevant in software development even today. The Agile Manifesto established some core elements of the best modern software development practices, which are still industry standard.  Examples of its influence include: Scrum:  A framework for small teams based on Agile Unified Process: A simplified version of The Unified Process (UP), or Unified Software Development Process Dynamic Systems Development:  An approach to project management and solution delivery Agile Alliance - Guide to Agile Practices: A collaboration between the Agile Alliance and PMI The emphasis on fast shipping had a major influence on changing the way physical goods are delivered around the globe.  WHAT DOES IT ALL MEAN? Agility means development with incremental approach, making small changes quickly, and learning from it through stakeholder feedback, making adjustments to our understanding of problems and repeating this many times. What to do: Find out and Plan the development incrementally within sprints. Initiate small steps towards your goal with quick deliveries. Adjust the understanding based on the feedback received. Lessons learnt should be implemented efficiently. Repeat all the steps. Below are a few simple steps that really describe what agile is all about.  Decide the goal to achieve. Perform small changes, test it, learn from it, adjust and repeat. Try to write code in agile way which is easy to change later. Implement small changes, get immediate feedback, initiate small iterations and make decisions that remove impediments for future changes as much as possible. Resolving problems using these basic agile principles, step by step at a time will ensure smooth transitions. The tools and methodologies will help to achieve agility. Avoid adding more processes.  Agile is a simple and fast way of learning and improving by taking small steps, one after the other. CONCLUSION Implementation of agile values to the project development process promotes communication both horizontally and vertically throughout the organization. It enhances innovation through high-performance multidisciplinary development teams and enhances business value by involving the client throughout the incremental delivery process. Improved communication, teamwork, collaboration, and organizational change improve the business value of products during the preliminary stages and throughout the project development lifecycle stages. Below are the concluding thoughts about Agile implementation Agile was born to simplify the lives of software developers, testers, and organizations. Transition from plan-based approach to Agile should result in the reduction of management overhead and lessen the burden of formalities from the creative development team. Be mindful of eliminating the right column of Agile Manifesto i.e., processes, tools, documentation, contract negotiation and the plan.  Agile methodology leads to avoiding misconceptions and helps in creating complex products. 
5366
12 Principles Behind the Agile Manifesto

Long before Agile came into existence, almost ev... Read More

Career Boost with CSM Certification

The ecosystem and landscape around every business is changing drastically. Digital technologies enable entities to develop digital products / services and to conduct their business significantly differently.  Example: Physical gift cards are now digital gift cards., like Amazon’s gift cards which can be shared with the near and dear ones during festive seasons or occasions. Customers can quickly buy this digital product online and gift it in a matter of a few seconds. This creates value for the customers and benefits the company that sells this product.  Organizations are heavily investing in newer technologies and at the same time focussing on refining their existing processes and working culture.  This enables them to increase and improve the speed and quality of the deliverables and also enhance customer experiences.  This is why global entities have taken on many best practices to contribute to the success of the interactions they have with different stakeholders. In this digital era, faster turnaround time is seen as one of the important traits of organizations developing and selling digital products. To accomplish this objective, IT organizations are exposed to a gamut of agile development models.   Today, “Scrum” (an agile development practice) is widely used as a mainstream practice in software development lifecycles, to create digital products like software. Let’s take a look at the overview of Scrum practices and understand how Certified ScrumMaster® (CSM®) certification can help you and your business. Scrum - an overview:Scrum methodology is based on principles like KISS (Keep It Simple & Straightforward) and progress iteratively with feedback.  This practice is: lightweight and implementable model. based on team collaboration. deceptively simple yet difficult to master.  based on “just enough” process and documentation mindset. An Analogy: Think about running a ten thousand metre race as a marathon run and slice the same race into some equal segments or sprints. Speed and quality increases when we slice the effort and maintain a constant pace or cadence.Scrum revolves around a concept called as “sprint” or a “timebox”.  So, sprint is a timebox of 2 to 4 weeks used to deliver some parts of the complete software in an iterative fashion. A simple sprint structure is expressed in the below diagram.  An Analogy: A teacher teaching the principles of abacus to the children divides the learners into four groups. The first set of children are beginners. They are taught to learn the abacus tools from scratch. They don’t have any targets as such. The second group of children know how to use the abacus tools and formulae. They are provided with a set of sums to solve with an upper time limit (for example 10 sets of sums in 10 to 15 minutes). The third set of children are in the advanced level. They are proficient enough to solve seventy to eighty sets of sums using abacus tools in less than five to seven minutes. Fourth set of expert level kids solve hundred plus sets of sums within five minutes with very minimal errors or no errors at all even without having a time pressure.  From the above analogy, we can conclude that when we repeatedly practice a simple method many times over and over, we gain perfection, maturity, speed and quality. We can now relate it with Scrum methodology. Scrum operates around simple processes which revolves around the Deming’s cycle (Plan-Do-Check-Act). Let’s get introduced to some of the basic elements of Scrum which revolves around roles, artifacts and ceremonies.  Basics of Scrum: Scrum Roles:   Product Owner: The Product owner understands business, customer, market and stakeholder needs. This role serves as the voice of the customer who is responsible for maximizing the value of the product or software.   Scrum Master :The Scrum Master is responsible for ensuring that Scrum is understood and enacted by all the stakeholders who interact with the scrum teams. Anyone who wears the cap of a Scrum Master has to take up a versatile range of roles such as facilitator, coach, mentor, trainer, enabler, change agent, servant leader etc.  Development Team:The Development Team consists of T-shaped professionals who do the work of delivering a potentially releasable increment or a minimum viable product at the end of each sprint. Cross-functional teams who can collaborate and self-organize are capable of delivering the products to the stated quality.   Scrum Artifacts: Product Backlog: The product backlog is simply all the things that need to be done within the project. In traditional project management, a product backlog can be referred to as a Requirements Documentation. This document is owned by the Product Owner and the requirements are prioritized based on the business value. Needs are captured in the form of user stories with acceptance criteria.  Example of a user story:  As a customer of the bank I want to update my latest communication address on my own using the bank’s app So that I can receive all the parcels/documents sent by the bank without missing them.Sprint Backlog: The Sprint backlog is a list of tasks identified by the scrum team to be completed during the sprint. During the sprint planning meeting, the team selects some number of product backlog items usually in the form of user stories, and identifies the tasks necessary to complete each user story. In traditional project management, this is also called as an Activity List.  Minimum Viable Product:  A Minimum Viable Product (MVP) is the sum of the Product Backlog items delivered during each sprint. Delivering the MVP in each sprint is fundamental to the scrum because when work is divided into simple pieces it can be finished in a short iteration. Example: An insurance company’s software development team is developing a mobile based app to sell their insurance products. In the first 3 sprints, the development team, delivers functionality and features that enable customers to buy insurance products online. Iteratively, the team delivers minimum viable products such as network locator, branch locator, feedback, track/modify policy, e-insurance card and so on.  Scrum Ceremonies: Sprint Planning:  The purpose of the sprint planning meeting is to estimate and forecast the work that can be accomplished by the team in the given sprint. Sprint backlog is the output of this meeting. Daily Stand-up: The purpose of the daily stand-up or daily scrum is to plan the day, identify risks and ways to mitigate them. Updated sprint backlog and burn charts / scrum board / Kanban board are the outputs of this activity.Sprint Review: The purpose of the sprint review is to showcase or demonstrate the developed feature to the product owner and other stakeholders. This promotes quick feedback.  Sprint Retrospective: The purpose of the sprint retrospective is to identify improvements and mature the ways of working in the subsequent sprints.Certified ScrumMaster (CSM) Certification from Scrum Alliance: This is an instructor-led training program designed and crafted to increase the knowledge base on fundamental elements of scrum practices in about sixteen hours. This program will be driven by a Certified Scrum Trainer® (CST®).  This certification is apt for professionals who: aspire to become a Scrum Master are project managers who encounter Scrum work with Scrum teams are Business Analysts who interact with Scrum teams are in IT Operations team and collaborate with Scrum teams want to begin their agile journey want to take other advanced certifications offered by Scrum Alliance want to learn the foundations of Scrum Exam:  After successfully completing the course, a candidate can take an online examination. 37 right answers out of 50 will enable a participant to earn the CSM certification. The time limit for the exam is 60 minutes.  Maintaining the certification :  Keeping the certification active is a good way to continue reaping the benefits of being certified. An active certification will help practitioners stay connected with the agile community, share and gain knowledge and help the community thrive. To keep the credential active, a renewal fee of $100 for two years is applicable. One also has to clock 20 learning hours called SEUs (Scrum Education Units®) once in two years towards maintaining the credential.  Benefits of CSM certification: helps in improving career prospects helps in marketability of one’s profile helps in demonstrating and improving the credibility of one’s profile Conclusion:  In a nutshell, Scrum is a software development framework which supports the value statements of the Agile Manifesto. Roles, artifacts and ceremonies of Scrum encourages “individuals and interaction” promoting a transparent, self-organizing, trustful, collaborative environment, focuses on delivering “working software” or minimum viable product with just enough documentation, promotes “customer collaboration” and infuses a mindset to “welcome changes” based on feedback and business value. Scrum facilitates a disciplined way to develop products in an iterative way using timeboxing as its core mantra.  Other agile practices such as Lean, Kanban, DevOps, Test Driven Development, Behaviour Driven Development, Feature Driven Development, eXtreme Programming, can be used alongside or to complement Scrum practices.  Scrum can also be scaled up to make it suitable to work with larger sets of teams. Existing project management practices can be tailored to infuse Scrum into their ways of working. Any organization adopting Agile, can kick start the adoption by embracing Scrum as a steppingstone. Although there are many different certifications available on agile practices, CSM is seen as a simple and easy way for professionals to begin their Scrum/Agile journey. As per the data published in www.scrumalliance.org there are more than a million professionals across the globe who are certified in various agile certifications offered by Scrum Alliance. So why wait? Grab your opportunity now! 
9563
Career Boost with CSM Certification

The ecosystem and landscape around every busines... Read More

ScrumXP

This article briefly talks about popular Agile methodologies Scrum and XP, and how both these frameworks have been merged into ScrumXP—giving you the best of both worlds!  Scrum Scrum is the leading Agile framework practiced in the industry today. It follows an iterative approach where development cycles are 2 /3/4 weeks long. At the end of every iteration an incremental version of the product/solution is ready to be shipped.  Scrum prescribes events / ceremonies and specific roles within the team in order to achieve alignment and agility.  Sprint Ceremonies /Events Sprint Planning at the start of the Sprint Daily Stand-up during the Sprint Sprint Demo and Review to showcase the incremental working software developed in the iteration Sprint Retrospective at the end of the Sprint Scrum Roles Product Owner – Responsible for the product that is being developed. Is the representative of the Customer and Business. Scrum Master – Facilitates and orchestrates the various Scrum events, guides the team to align with Scrum values and principles. Team Member – Focusses on achieving Sprint goals, continuously strives to improve. Scrum Values  Courage - Every team member feels safe to fail and learn, to seek help, to say ‘no’ and question something that is going wrong. Commitment – Commits to Sprint goals as a team. Does not overcommit.  Focus - Aims to complete what is started and steer away from distractions and unprioritized/ "shoulder tap" work. Limits Work in Progress. Openness - Seeks and values feedback and opportunities to learn. Makes impediments, failures and learnings visible. Respect - Team collaborates and acknowledges the work and achievements of every member. Builds trust. Extreme Programming (XP) XP is one of the earliest ,most successful and proven Agile Methodologies.  It is very specific regarding the practices to be followed. XP is recommended to be used when the Customer is fully committed to deep involvement with the development team. XP teams rapidly produce software in short(mostly one week) iterations taking immediate feedback from the Customer. XP Values Communication – Communication within the team is as important as communication with the Customer Simplicity - Building a system that is easy to revise and maintain. Trying not to engineer too many and too much and only do what is required at that time. Feedback – Continuously striving to obtain feedback and acting on the feedback from Customer, Team and the Product. Courage – Courage to persevere and do the right thing. Respect – Respect for fellow team members and all stakeholders. XP Core Practices XP mandates certain core Engineering practices that distinguish this Agile methodology from the others. These practices take care of different aspects of agility and are interconnected at the same time.  They are grouped as below. Fine scale feedbackWhole TeamAll the contributors to a project – Developers, Testers, Analysts, Coaches etc who are part of the Project are part of the “Whole Team” that is centered around the Customer.Planning GameThe Customer presents the desired features and lays out an initial plan for the project. XP teams revise the release plan regularly.During Iteration Planning, the Customer presents the features desired for the next two weeks. XP teams build software in two-week “iterations”, delivering running, useful software at the end of each iteration.The total involvement by the Customer during Planning is an important practice of XP.Pair ProgrammingAll production code is touched by two team members. This ensures there is already another “reviewer” at work as the code is getting produced. This practice largely avoids bugs and coding errors.Test Driven DevelopmentTest before code is religiously practiced. Before a single line of code is written, a test for the same has to be written and run. This immediate and short feedback loop immensely helps to avoid waste, like bugs and wrong code.Customer TestsAcceptance Tests are defined by the Customer to validate if the features that are being introduced are fit to the purpose. The team automates these tests and builds a suite of such tests to run whenever required and to get immediate feedback from the system to check if all is well.Continuous processContinuous IntegrationContinuously integrating the code avoids the major problems that creep up when it is done  just before the release. Testing on a fully integrated system helps to detect critical bugs that might otherwise stay undetected for long.Design ImprovementDesign Improvements and Refactoring happens at healthy intervals to ensure system is cohesive and loosely coupled. This ensures the system can be easily extended with new features, scaled when required and maintained in good health.Small ReleasesWorking Software is delivered to Customer at the end of every iteration – either for actual use or evaluation and to obtain feedback.Shared understandingCoding Standards are practiced so that there can be collective ownership and any team member will be able to understand the code.Pair Programming and Coding Standards ensure that code is not owned by one single person and is the responsibility of the team.Design is kept simple and continuously improved and revised to cater to the current functional demands. Design is not done up-front but done at regular intervals.XP teams use a common system of names to ensure a common understanding of the system.Programmer welfareSustainable PaceXP ensures the team members work at a pace that can be carried out for a very long time.  The system avoids situations where the team members are left wanting for work at times and then have to scramble to finish deadlines.Scrum and XP – What is common and different. Scrum and XP are two popular Agile Methodologies having the same larger goal of delivering to the customer incrementally and iteratively. Both the methodologies lay great importance to customer centricity, feedback mechanisms, continuous improvement and building sustainable empowered teams.  There are few differences in the implementing mechanisms of these methodologies.  Iteration Duration: Scrum Iterations last for 2 /3/ 4 weeks. XP iterations are usually very short – one week long or at the most 2 weeks. Role of the Customer: XP and Scrum have Release Planning and Iteration Planning sessions. But unlike Scrum, in XP the Customer drives the planning and schedules the Release.  The Customer continuously interacts directly with the Teams in XP, while in Scrum the Product Owner represents the Customer and Business. The XP teams ensure to deliver a working bug free system at the end of every iteration. Customer chooses to evaluate and provide feedback or Release to the end users. Scrum teams deliver working software at the end of every iteration. The Product Owner with the input from teams decides on the right time for General Availability (GA) Release depending on the Market Readiness, Customer input etc. Practices: Scrum recommends using Engineering Best Practices like TDD, Pair Programming, Code Refactoring etc. but XP takes it to another level by mandating these Engineering Practices. Scrum recommends that items planned within a Sprint are unchanged until the end, but in XP, teams accommodate a sudden change of priority even during the iteration, by swapping items if work has not started on it. Roles: Scrum has dedicated Scrum Ceremonies whereas XP does not prescribe it per se. Scrum has a dedicated Scrum Master who facilitates these events, but XP does not have a Scrum Master.  XP teams get guidance from Agile Coaches.  ScrumXP- Using the best of Scrum and XP Practices When there are two great practices, there is always a tendency to combine both and get the best of both the worlds. “Lean-Agile”, “Scrumban”, “ScrumXP” are some examples of hybrid terms that have become increasing popular by combining two philosophies (e.g Lean and Agile ) or two methodologies (e.g Scrum and Kanban / Scrum and XP). ScrumXP is a hybrid practice making the most of both Scrum and XP. XP has laid out some very effective Engineering practices that teams practicing Scrum can greatly benefit from.  Many teams practice Scrum as their process framework and include the very effective and efficient core Engineering XP Practices in their way of working. This gives rise to the highly productive ScrumXP hybrid model of working. Mostly the ScrumXP teams retain the Scrum Master and Product Owner roles within their teams to take care of the required orchestration and facilitation. ScrumXP and SAFe “Team and Technical Agility” is one of the key competencies of SAFe. By following  ScrumXP the SAFe teams take care of the team Agility through Scrum Practices and Technical Agility through XP Practices.  The robust Engineering practices of XP ensures the product being built is of very high quality, easily extendable, maintainable and sustainable. In conclusion, ScrumXP provides the best of both worlds. Teams can begin with Scrum and continuously improve by including the robust core XP Engineering practices like TDD, pair programming, code refactoring etc— not because it is mandated but because they find it effective. Although, interaction with the Customer is through a Product Owner, the Scrum teams can borrow the Customer Centric approach of XP to remain aligned with Customer expectations. 
5365
ScrumXP

This article briefly talks about popular Agile m... Read More