Search

What Is Iteration Planning and How to Do It Effectively?

Iteration planning is considered as the lifeline of Agile framework and plays an important role in the cadence delivery of the product in incremental releases. It is very critical to do iteration planning effectively to ensure we remain productive and add business value with each sprint. An Iteration Preparation Meeting is a crucial ceremony during an IT project development stage for every Agile team that uses Scrum. It's where the team gets together in the next Iteration to chat about work and is structured to help provide a consistent focus and direction for the work ahead. Iteration Planning (Overview)Iteration planning is one of the important ceremonies in the Agile framework. The aim of iteration planning is to set a few high-level goals for what to achieve during the iteration, to create a sufficiently comprehensive plan detailing who needs to do what to achieve those goals, and to determine how to measure what you have achieved. Iteration planning is usually conducted at the start of an iteration with the entire team in a group, including key stakeholders, generally lasting one to a few hours. It means that the whole team knows what needs to be achieved, and they are committed to the results of the team.  In certain cases, it is preferred to allow a smaller subset of individuals, such as the project manager, an architect and an analyst to meet in advance with a draft iteration plan. For the team to complete the collection of top-ranked product backlog products, the iteration planning plays an important role. Based on the duration of iteration and team velocity, this is a time-boxed arrangement. A crucial feature of an iteration is to concentrate the team on a measurable benefit that is deliverable in the short term. To make sure that you do not lose concentration on what to achieve during the iteration, document 1-5 high-level targets. Usually, for each iteration, the project plan may specify one or more goals, and those goals are used as a starting point. If you need to explain the goals when you prepare your iteration, do so. Inputs to IP & Planning the Iteration:  The IP goals are typically based on the following factors: Critical risks not yet mitigated: Iteration priorities also involve the most significant risks being pushed down.  The time allocated to the iteration: Iterations are timeboxed, so the Project Manager must ensure that the iteration priorities are achievable in relation to the time and resources allocated to the iteration.  The highest priority features: To ensure that the essential features of the application are built and checked early on, specifications are prioritized. Iteration Planning Steps- Before starting, make sure, the user story in the product backlog have been sized by the team and a relative story point value has been assigned. The product backlog is stacked to reflect the product owner 's preferences. For these rated backlog products, there is a general understanding of the acceptance requirements. Per iteration, there is an iteration plan that can describe who will execute the work item for how long a time.  Since iterations are time-boxed, by calculating how many hours of real work can be taken on, we need to consider how big our 'box' is. Let's say you have 6 team members, and you have 15 working days in your iteration, and you can do 5 real hours of work per person and day on average. This will earn you 6x15x5h = 450 real work hours. Notice that only 4-6 hours of actual project work every day is done by the average team member, with the remainder being consumed by e-mails, meetings, and other routine tasks not specifically related to the project. For all the high-priority items in the Work Items List, the team can then review and amend priorities to ensure that a significant work item is not skipped, which will otherwise fall far below the list of what can be taken on in this iteration. The essential features for a product backlog item for the purpose of iteration planning are:  The iteration is small enough to be done.  We can check whether it was correctly implemented or not. There are two steps in designing the contents of an iteration: deciding how many user stories will fit into the iteration, then breaking down those stories into assignments and appointing owners. Sizing refers to a user story's relative reach, which is normally performed in relative points. When it is first developed, during backlog refining sessions, and before the planning meeting, the team regularly estimates the size of a user story. The team should know what story at the top of the backlog will fit into the iteration by the time preparation starts. Estimation refers to the breakdown of tasks into a user narrative. When the steps taken to produce a user story are established, an hourly estimate is provided for each mission. This figure keeps the team updated on how close it is to completing a mission. The team also recognizes how many task hours each member of the team has available in the iteration (known as capacity) to avoid overburdening of individuals. In planning sprints, there are two general approaches: velocity-driven planning and capacity-driven planning. Velocity driven Sprint Planning  Let 's start with velocity-driven sprint planning since it's the simplest to explain. Velocity-driven sprint preparation is based on the idea that in the next sprint, the amount of work a team can perform is approximately equal to what they have done in previous sprints. This implies, of course, that the team is working on similar work from sprint to sprint, consistent sprint lengths, and so on, such as a constant team size. Each of these assumptions is usually true and violations of the assumptions are easily recognized that is, the team knows this in advance when a sprint switches from 10 to nine working days, as in the case of a holiday. \The following are the phases in velocity-driven sprint planning:  Determine the historical average velocity for the team.  Select the number of items for the product backlog equal to that velocity.  Most teams stop there. Others include an extra step:  Identify the activities involved in the user stories chosen to see if it feels like the correct amount of work.  And there will be some teams moving even further to:  Estimate the assignments to see if the task total is in line with previous sprints. Capacity driven planning The product owner, the Scrum Master and all members of the agile team are involved in a capacity-driven sprint planning meeting. The product owner brings into the meeting the top-priority product backlog items and presents them to the team, usually beginning with a summary of the high-priority items collection. After a high-priority item has been selected, team members discuss the work involved and determine the activities needed to produce the product backlog item. The hours for each item would also be approximately calculated by most teams. These figures are tentative since the figures can only be used to impact the number of items that are brought into the sprint and the product backlog. Estimates do not need to be accurate to do so. Do not ask or expect a team to think about any job that will be completed during the sprint. That is not only unlikely, it is needless, too.  The team members ask themselves, "Should we commit to this?" after they have defined tasks and approximately calculated the hours for that one product backlog item. When the team decides that a product backlog item can be shipped, they pick another item and repeat the procedure. And they continue to repeat it until anyone says that they are unable to commit to the product backlog item chosen. If someone is unable to complete the item in the sprint, team members can normally address the situation and see if someone else is available to help. Maybe a DBA with rudimentary JavaScript expertise will assist an exhausted developer of JavaScript. You may have noted that no story point or velocity has played a role in the process so far. Although I still recommend providing rapid, high-level estimates of product backlog items in story points.  Iteration Planning Attendees -These are the below attendees for IP ceremonies: Scrum Master-The scrum master serves as an agile distribution team facilitator.  Product Owner: The product owner deals with the comprehensive view and approval conditions of the product backlog.  Agile Team : Agile implementation determines their objectives and sets the estimates of effort necessary for the commitment to be met. Iteration Planning Agenda : The following is an example agenda for iteration planning:  Measure the iteration's available team capacity.  Discuss each story, discuss extensive acceptance requirements, and use story points to provide estimates.  When the team runs out of capacity, preparation ends. Determine and settle on the objectives for iteration. All should be committed to their goals.  Criteria for acceptance are created through dialogue and cooperation with the product owner and other stakeholders. The Product Owner may adjust the rating of the story based on the story's estimates. Velocity Calculation Velocity is a measure of the amount of work that a team can do during a single sprint and is Scrum 's main metric. Velocity is determined by summing the points for all completely completed User Stories at the end of the Sprint. Dividing the total number of story points completed by the number of sprints includes the real velocity. For instance, if a total of 70 points were achieved by the development team over two sprints, the actual velocity of the team will be 35 points per sprint. Capacity planning The agile team quantifies their capacity to do work. Each member of the team decides their availability, considers time off and other possible responsibilities. Other standing responsibilities, such as maintenance, are also taken into account in this operation, which is distinct from the creation of new stories. Using their historical velocity as a starting point, the team makes changes to assess the actual potential for the iteration based on the unavailable time and team members. Story Analysis & EstimationThe team backlog is checked once the team capacity has been identified. Each story, covering relative difficulty, scale, complexity, ambiguity, technical challenges, and requirements for acceptance, is addressed. In order to maintain a common understanding of the individual behavior of each story, teams also use Behavior-Driven Production (BDD). Finally, for the story, the team agrees to a size estimate. Usually, there are also other types of stories on the team backlog, including enablers that might represent infrastructure work, POC, and architectural improvements, as well as work and defect refactoring. They also prioritize and estimate these things. In Scrum, the estimation of the story point of the team, and the resulting velocity, is usually a local and independent matter. The fact that a small team might estimate their velocity to be 50 in such a way, while another larger team estimates that their velocity is 13, is typically not a concern. However, in SAFe, the calculation of the story point must be standardized, so that assessments of features or epics that require the help of several teams are based on the same concept of the story point, allowing a common economic decision-making basis Relative Estimating, Velocity, Capacity, and Normalizing Story Point Estimating- In order to reasonably estimate a story, Agile teams use story points. With relative estimation, the size (expected effort) is compared to another story for each story. An eight-point story, for instance, is four times the effort of a two-point story. The pace of the team is equivalent to the historical average of all completed stories per iteration. The starting point for estimating the potential of a team for a future iteration is velocity. Knowing the skill of a team helps with preparation and helps to restrict Work in Process (WIP). Teams should not take on more stories than their previous pace would imply. Velocity, which is also forecast in story points, is also used to estimate how long it takes to deliver features or epics. Develop/commit to Iteration GoalsWhen the iteration backlog is known, the team turns its focus to synthesizing one or more iteration priorities that outline the work in that iteration that the team intends to achieve. They are based on the iteration backlog from the PI planning case, as well as the team and program PI goals. The closer the PI planning session is to the IP version, the more likely the PI targets will stay unchanged. When the potential of the team has been met, no more stories are taken from the team backlog in terms of committed stories. At this point, the product owner and the team settle on the final list of stories that will be chosen, and the iteration priorities will be revisited and reaffirmed. The entire team then agrees to the objectives of the iteration, and for the duration of the iteration, the nature of the work remains set. Guidelines for Effective IPSome tips for holding an iteration planning meeting are given below: Keep an eye of duration of this event. It should be timeboxed to 4 or less hours. It should be organized by the team and for the team alone. We should keep a check on the historical velocity of team before over-committing the team’s capacity. Source: https://www.scaledagileframework.com/iteration-planning/#:~:text=Iteration%20Planning%20is%20an%20event,set%20of%20committed%20Iteration%20Goals. Conclusion (Summary) It is important to ensure that the way you will assess progress at the end of the iteration is transparent to all team members and other stakeholders. The obvious criterion for success should be that you can verify the implemented features. Iteration preparation, either on the first day or a week before the iteration starts, should be performed once per iteration. You should give about 12 hours to finish the process as a facilitator, but there is really no fixed time, it's all about whatever works for your team. Most notably, have fun and remember to celebrate the previous success of Iteration! 

What Is Iteration Planning and How to Do It Effectively?

6K
  • by Ashish Kumar
  • 21st Dec, 2020
  • Last updated on 21st Dec, 2020
  • 8 mins read
What Is Iteration Planning and How to Do It Effectively?

Iteration planning is considered as the lifeline of Agile framework and plays an important role in the cadence delivery of the product in incremental releases. It is very critical to do iteration planning effectively to ensure we remain productive and add business value with each sprint. An Iteration Preparation Meeting is a crucial ceremony during an IT project development stage for every Agile team that uses Scrum. It's where the team gets together in the next Iteration to chat about work and is structured to help provide a consistent focus and direction for the work ahead. 

Iteration Planning (Overview)

Iteration planning is one of the important ceremonies in the Agile framework. The aim of iteration planning is to set a few high-level goals for what to achieve during the iteration, to create a sufficiently comprehensive plan detailing who needs to do what to achieve those goals, and to determine how to measure what you have achieved. Iteration planning is usually conducted at the start of an iteration with the entire team in a group, including key stakeholders, generally lasting one to a few hours. It means that the whole team knows what needs to be achieved, and they are committed to the results of the team.  

In certain cases, it is preferred to allow a smaller subset of individuals, such as the project manager, an architect and an analyst to meet in advance with a draft iteration plan. For the team to complete the collection of top-ranked product backlog products, the iteration planning plays an important role. Based on the duration of iteration and team velocity, this is a time-boxed arrangement. Product Backlog   Iteration Backlog

A crucial feature of an iteration is to concentrate the team on a measurable benefit that is deliverable in the short term. To make sure that you do not lose concentration on what to achieve during the iteration, document 1-5 high-level targets. Usually, for each iteration, the project plan may specify one or more goals, and those goals are used as a starting point. If you need to explain the goals when you prepare your iteration, do so. 

  • Inputs to IP & Planning the Iteration 

The IP goals are typically based on the following factors: 

Critical risks not yet mitigated: Iteration priorities also involve the most significant risks being pushed down.  

The time allocated to the iteration: Iterations are timeboxed, so the Project Manager must ensure that the iteration priorities are achievable in relation to the time and resources allocated to the iteration.  

The highest priority features: To ensure that the essential features of the application are built and checked early on, specifications are prioritized. 

  • Iteration Planning Steps- Before starting, make sure, the user story in the product backlog have been sized by the team and a relative story point value has been assigned. The product backlog is stacked to reflect the product owner 's preferences. For these rated backlog products, there is a general understanding of the acceptance requirements. Per iteration, there is an iteration plan that can describe who will execute the work item for how long a time.  

Since iterations are time-boxed, by calculating how many hours of real work can be taken on, we need to consider how big our 'box' is. Let's say you have 6 team members, and you have 15 working days in your iteration, and you can do 5 real hours of work per person and day on average. This will earn you 6x15x5h = 450 real work hours. Notice that only 4-6 hours of actual project work every day is done by the average team member, with the remaindebeing consumed by e-mails, meetings, and other routine tasks not specifically related to the project. For all the high-priority items in the Work Items List, the team can then review and amend priorities to ensure that a significant work item is not skipped, which will otherwise fall far below the list of what can be taken on in this iteration. The essential features for a product backlog item for the purpose of iteration planning are:  

  • The iteration is small enough to be done.  
  • We can check whether it was correctly implemented or not. 

There are two steps in designing the contents of an iteration: deciding how many user stories will fit into the iteration, then breaking down those stories into assignments and appointing owners. Sizing refers to a user story's relative reach, which is normally performed in relative points. When it is first developed, during backlog refining sessions, and before the planning meeting, the team regularly estimates the size of a user story. The team should know what story at the top of the backlog will fit into the iteration by the time preparation starts. Estimation refers to the breakdown of tasks into a user narrative. When the steps taken to produce a user story are established, an hourly estimate is provided for each mission. This figure keeps the team updated on how close it is to completing a mission. The team also recognizes how many task hours each member of the team has available in the iteration (known as capacity) to avoid overburdening of individuals. 

  • In planning sprints, there are two general approaches: velocity-driven planning and capacity-driven planning. 
  • Velocity driven Sprint Planning 

 Let 's start with velocity-driven sprint planning since it's the simplest to explain. Velocity-driven sprint preparation is based on the idea that in the next sprint, the amount of work a team can perform is approximately equal to what they have done in previous sprints. This implies, of course, that the team is working on similar work from sprint to sprint, consistent sprint lengths, and so on, such as a constant team size. Each of these assumptions is usually true and violations of the assumptions are easily recognized that is, the team knows this in advance when a sprint switches from 10 to nine working days, as in the case of a holiday. \

  • The following are the phases in velocity-driven sprint planning:  
  • Determine the historical average velocity for the team.  
  • Select the number of items for the product backlog equal to that velocity.  

Most teams stop there. Others include an extra step 

  • Identify the activities involved in the user stories chosen to see if it feels like the correct amount of work.  

And there will be some teams moving even further to 

  • Estimate the assignments to see if the task total is in line with previous sprints. 

Capacity driven planning 

The product owner, the Scrum Master and all members of the agile team are involved in a capacity-driven sprint planning meeting. The product owner brings into the meeting the top-priority product backlog items and presents them to the team, usually beginning with a summary of the high-priority items collection. 

After a high-priority item has been selected, team members discuss the work involved and determine the activities needed to produce the product backlog item. The hours for each item would also be approximately calculated by most teams. These figures are tentative since the figures can only be used to impact the number of items that are brought into the sprint and the product backlog. Estimates do not need to be accurate to do so. Do not ask or expect a team to think about any job that will be completed during the sprint. That is not only unlikely, it is needless, too.  

The team members ask themselves, "Should we commit to this?" after they have defined tasks and approximately calculated the hours for that one product backlog item. When the team decides that a product backlog item can be shipped, they pick another item and repeat the procedure. And they continue to repeat it until anyone says that they are unable to commit to the product backlog item chosen. If someone is unable to complete the item in the sprint, team members can normally address the situation and see if someone else is available to help. Maybe a DBA with rudimentary JavaScript expertise will assist an exhausted developer of JavaScript. 

You may have noted that no story point or velocity has played a role in the process so far. Although I still recommend providing rapid, high-level estimates of product backlog items in story points.  

  • Iteration Planning Attendees -These are the below attendees for IP ceremonies: 
  • Scrum Master-The scrum master serves as an agile distribution team facilitator. 
  •  Product Owner: The product owner deals with the comprehensive view and approval conditions of the product backlog. 
  •  Agile Team : Agile implementation determines their objectives and sets the estimates of effort necessary for the commitment to be met. 
  • Iteration Planning Agenda : The following is an example agenda for iteration planning:  
    • Measure the iteration's available team capacity.  
    • Discuss each story, discuss extensive acceptance requirements, and use story points to provide estimates.  
    • When the team runs out of capacity, preparation ends. 
    • Determine and settle on the objectives for iteration. All should be committed to their goals.  

Criteria for acceptance are created through dialogue and cooperation with the product owner and other stakeholders. The Product Owner may adjust the rating of the story based on the story's estimates. 

  • Velocity Calculation 

Velocity is a measure of the amount of work that a team can do during a single sprint and is Scrum 's main metric. Velocity is determined by summing the points for all completely completed User Stories at the end of the Sprint. Dividing the total number of story points completed by the number of sprints includes the real velocity. For instance, if a total of 70 points were achieved by the development team over two sprints, the actual velocity of the team will be 35 points per sprint. 

  • Capacity planning 

The agile team quantifies their capacity to do work. Each member of the team decides their availability, considers time off and other possible responsibilities. Other standing responsibilities, such as maintenance, are also taken into account in this operation, which is distinct from the creation of new stories. Using their historical velocity as a starting point, the team makes changes to assess the actual potential for the iteration based on the unavailable time and team members. 

  • Story Analysis & Estimation

The team backlog is checked once the team capacity has been identified. Each story, covering relative difficulty, scale, complexity, ambiguity, technical challenges, and requirements for acceptance, is addressed. In order to maintain a common understanding of the individual behavior of each story, teams also use Behavior-Driven Production (BDD). Finally, for the story, the team agrees to a size estimate. Usually, there are also other types of stories on the team backlog, including enablers that might represent infrastructure work, POC, and architectural improvements, as well as work and defect refactoring. They also prioritize and estimate these things. 

In Scrum, the estimation of the story point of the team, and the resulting velocity, is usually a local and independent matter. The fact that a small team might estimate their velocity to be 50 in such a way, while another larger team estimates that their velocity is 13, is typically not a concern. However, in SAFe, the calculation of the story point must be standardized, so that assessments of features or epics that require the help of several teams are based on the same concept of the story point, allowing a common economic decision-making basis 

  • Relative Estimating, 

Velocity, Capacity, and Normalizing Story Point Estimating- In order to reasonably estimate story, Agile teams use story points. With relative estimation, the size (expected effort) is compared to another story for each story. An eight-point story, for instance, is four times the effort of a two-point story. The pace of the team is equivalent to the historical average of all completed stories per iteration. The starting point for estimating the potential of a team for a future iteration is velocity. Knowing the skill of a team helps with preparation and helps to restrict Work in Process (WIP). Teams should not take on more stories than their previous pace would imply. Velocity, which is also forecast in story points, is also used to estimate how long it takes to deliver features or epics. 

  • Develop/commit to Iteration Goals

When the iteration backlog is known, the team turns its focus to synthesizing one or more iteration priorities that outline the work in that iteration that the team intends to achieve. They are based on the iteration backlog from the PI planning case, as well as the team and program PI goals. The closer the PI planning session is to the IP version, the more likely the PI targets will stay unchanged. When the potential of the team has been met, no more stories are taken from the team backlog in terms of committed stories. At this point, the product owner and the team settle on the final list of stories that will be chosen, and the iteration priorities will be revisited and reaffirmed. The entire team then agrees to the objectives of the iteration, and for the duration of the iteration, the nature of the work remains set. 

  • Guidelines for Effective IP

Some tips for holding an iteration planning meeting are given below: 

  • Keep an eye of duration of this event. It should be timeboxed to 4 or less hours. 
  • It should be organized by the team and for the team alone. 
  • We should keep a check on the historical velocity of team before over-committing the team’s capacity. 

Source: https://www.scaledagileframework.com/iteration-planning/#:~:text=Iteration%20Planning%20is%20an%20event,set%20of%20committed%20Iteration%20Goals. 

Conclusion (Summary) 

It is important to ensure that the way you will assess progress at the end of the iteration is transparent to all team members and other stakeholders. The obvious criterion for success should be that you can verify the implemented features. Iteration preparation, either on the first day or a week before the iteration starts, should be performed once per iteration. You should give about 12 hours to finish the process as a facilitator, but there is really no fixed time, it's all about whatever works for your team. Most notably, have fun and remember to celebrate the previous success of Iteration! 

Ashish

Ashish Kumar

Senior Technology Specialist

Ashish is working as a Senior Technology Specialist in leading financial bank has more than 13 years of experience in developing enterprise applications

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. 
5368
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! 
9564
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. 
5364
ScrumXP

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