Articles

Agile estimation tools are essential in project management, facilitating accurate and efficient planning in iterative development cycles. These tools, such as Planning Poker, T-shirt Sizing, and the Fibonacci sequence, help teams estimate the effort and complexity of tasks collaboratively. By promoting consensus and leveraging collective team insights, they ensure more reliable forecasts and enhance flexibility in adjusting to changing requirements. Agile estimation tools also support continuous improvement and transparency, enabling teams to track progress and make informed decisions throughout the development process.

Agile integration tools are essential for seamless collaboration and efficiency in Agile environments. These tools facilitate communication, automate workflows, and integrate various development and project management systems. By streamlining processes and enhancing transparency, Agile integration tools empower teams to deliver high-quality products faster, ensuring continuous improvement and alignment with business goals.

Agile Master Practices encapsulate principles and methodologies essential for effective Agile project management. These practices encompass a dynamic approach to project execution, emphasizing collaboration, adaptability, and continuous improvement. Key practices include fostering open communication within cross-functional teams, promoting iterative development cycles, and embracing change as a catalyst for innovation. Additionally, Agile Master Practices advocate for transparent decision-making processes, empowering teams to self-organize and take ownership of project outcomes.

Scrum agile practices encompass a set of principles and methodologies aimed at promoting flexibility, collaboration, and continuous improvement within project management. Key practices include iterative development cycles known as sprints, typically lasting two to four weeks, during which teams deliver incremental pieces of working software.

Project Management Institute’s “PMI Agile Certified Practitioner Exam Content Outline” organizes the tasks practitioners do when working in Agile environment into six domains. Their exam does not test specifically on the domains, so learning their grouping of tools and techniques and knowledge and skills will not be directly applicable to the language of the test. However, this organizational way of looking at Agile tools and tasks has been done to help practitioners learn and understand Agile better.

The six domains of Agile are:

• Value-driven delivery
• Stakeholder engagement
• Boosting team performance
• Adaptive planning
• Problem detection and resolution
• Continuous improvement

Let’s discuss each domain in more detail.

Value-driven delivery

Creating value is at the core of any project, and Agile methods are designed with the core objective of delivering value on a knowledge worker project. While maximizing value, Agile also has tools and techniques to minimize risks that can erode value. Agile methods also place importance on the customer’s priorities and is designed to deliver elements that have the highest value to the customer first.

Assessing value –.

Planning value – We create a charter detailing the scope, objective, and other attributes of the project. We then use tools such as customer-valued prioritization, relative prioritization, and risk adjusted backlog while preparing the priority list. Which planning value, we also assess the contracting costs of the project.

Delivering value – After planning how we are going to deliver value, we focus on eliminating all activities that do not add value. We can use task and Kanban boards to schedule the backlog. Limiting the Work in Progress (WIP) reduces the potential for reworking and keeps the project going smoothly.

Confirming value – We have executed tasks and created value but is this what the customer wanted? We have to confirm the value we are delivering to know this. We demonstrate prototypes, simulate functionalities to help the customer test the product and see how they work.

Tracking and reporting value – It is not enough that we just deliver value. It is important that we regularly track the rate of delivery of value so that it can be communicated to business stakeholders. Cumulative flow diagrams and burn down graphs are an easy and informative way through which we can assess the development of the project.

Stakeholder engagement

Stakeholders in a project can be anybody who can negatively or positively impact a project. They can be business representatives, customers, the project manager, the development team, or external vendors contributing directly or indirectly to the project. Stakeholder engagement becomes important, because software development involves creating intangible products and the team must have a precise understanding of customer requirements.

Agile projects are subject to constant change which makes it essential that a clear and steady channel of communication is established. All stakeholders must be involved in the project to ensure that it stays on the right track. Teams can use tools such as wireframes, user stories, a user story backlog, and personas to verify their understanding of customer requirements.

Face-to-face communication is the most preferred method of communication on agile projects. They provide the maximum amount of information in the least amount of time. Information radiators such as burn down charts, cumulative flow diagrams, and velocity tracking charts allow us to determine progress of the project, which can be communicated to all the stakeholders.

Soft skills play an important role while engaging with stakeholders. Soft skills such as negotiating and active listening are necessary while dealing with customers. It is also essential that we be familiar with implementing soft skills such as facilitation methods, participatory decision models, and conflict resolution that are primarily concerned with managing teams.

When we talk of managing teams, our leadership skills play a crucial role. Servant leadership is an extremely effective way of leading teams. A servant leader encourages the team to excel by removing any obstacles, motivate and reward the team’s performance.

Boosting team performance

The third domain in Agile deals with boosting team performance practices. In software development, “people factors” incur the highest cost. Therefore, it is extremely important that we obtain the highest return on performance.

The process of forming a team is one of the determinants of success on a project. Building a team goes through the stages of forming (identifying potential team members and bringing them together), storming (the team collaborates and comes up with ideas), norming (teams form rules and normalize their working patterns), and performing (the team works together). During each of these phases, it is important for a leader to know when to play a supporting or directing role. For example, during the storming phase, conflicts can be frequent and the leader will have to step in to help the team members develop methodologies to resolve them.

To get the best out of a team, it should be self-organizing and self-directing. Allowing teams to be self-organizing and self-directing enables team members to manage complex tasks by themselves and figure out the best way to complete the tasks. This capitalizes on the team’s combined expertise and talent.

There are several activities that can help a team boost their performance on Agile projects. Daily stand-up meetings are a quick way to communicate the team’s performance status and identify present and potential issues. To overcome issues and improve continuously, teams might need to be mentored at different stages. During events such as iteration planning meetings or retrospectives, teams might need to be coached at a group level and mentoring can be provided for individual team members when the iteration is underway.

Brainstorming sessions can be used by teams to resolve issues, improve, and innovate processes. Because face-to-face communication is the ideal way to communicate on Agile projects, it is important that the team be located in a common area with space for whiteboards and other information radiators.

Adaptive Planning

Because extensive planning before the project is undertaken can be cumbersome and often does not add any real value, Agile calls for an adaptive approach to planning. Adaptive planning involves creating a basic plan and updating it as the project gets underway. Adaptive planning requires practitioners to maintain close collaboration with the customer to understand his or her requirements more accurately. Collaborative games such as remember the future, prune the product tree, buy a feature, and bang-for-the-buck can be used to help the development team understand customer requirements better.

To make timely deliveries, team members should calculate their estimates as accurately as possible factoring in all diversions and constraints. Wideband Delphi and Ideal Time are some of the techniques which can help teams arrive at an accurate estimate. While estimating the cost of the project, the figures should be presented in ranges as they seem more credible than pin-point figures that can have an air of false confidence.

Iteration and release planning is a vital part of adaptive planning. Releases are bundles of functionality that can be delivered to a customer. While planning a release, the Product Owner/manager, development team, and Agile Expert can use a velocity chart to determine how many features can be completed by the team in a given time.  While planning iterations, it important to have a fixed priority list at the beginning of the planning session. Team members have the final say on how much work can be completed, while the product owner gets the final say on the priority of the items included for the iteration. Availability of team members needs to be factored in while planning iterations.

Problem Detection and Resolution

A common saying is, “A stitch in time saves nine,” and this couldn’t be more apt to explain how Agile methods deal with problems. If ignored, problems can have a devastating effect on the project as they not only increase the burden of rework; they make the team fall behind in its plans. It is a double whammy for the team when this happens as it takes twice the resources. Agile practices aids in detecting problems as early as possible and fixing them while they are still small.

Detecting problems is the first step to resolving them. Daily stand-up meetings are an excellent way to identify any issues that team members are facing.  Teams can also track issues by calculating cycle times for tasks. If the cycle time is too high, it might indicate a potential problem or that the team has undertaken more work than it can complete. Limiting work in progress can help monitor the project timeline better and track problems more easily. Despite our best efforts, some defects may make their way through to the final product. Escaped defects are the most expensive to fix. Teams can track escaped defects on a graph to analyze trends. This can help refine quality control processes.

Alistair Cockburn describes “failure modes and alternatives,” that are related to the human aspect of performance. Cockburn says that people fail because they can be inconsistent at following a technique, are creatures of habit and prefer to invent new ways than modify existing reliable methods. To counter “failure modes” Cockburn advises that teams should inculcate discipline, receive feedback regularly, and assign work based on personalities of individual team members.

Resolving issues that are identified is the next step. Continuous integration of new code, as and when it is developed, in a repository can help overcome the issues that we find with integration. Validating progress at frequent intervals and at different levels can help us be confident that our work is error-free.

In software development, commonly used techniques are Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD). These methods primarily involve writing the tests before any code is written. The codes are written until they pass the tests. Codes might then be “refactored” if necessary, which involves refining the design without altering its behavior.

Continuous Improvement

New insights and learning gained on a traditional project is typically gathered at the end of the project cycle. These insights might not be of much help on the next project unless the two are very similar. That learning could have had more value, if it had been used on the project in which it was learned. Agile methodology seeks to continuously improve throughout the project and encourage applying lessons to the development process as and when we learn it. Retrospectives at the end of each iteration makes the lessons learned available for the very next iteration.

A retrospective typically lasts for about two hours during which time the team gathers data about the different challenges that it faced and the various lessons learned while solving them. The learning is analyzed to see if there exists underlying patterns or any insights. Armed with these patterns and insights, the team plans the next iteration.

As part of continuous improvement, team members should be encouraged to share knowledge they acquire, with other team members. One of the reasons colocation is stressed in Agile projects is because it provides a platform for knowledge sharing through face-to-face communication. To encourage knowledge sharing, team velocity can be tracked at a team level rather than measuring it at an individual level, so that team members are motivated to help each other.

We might be required to tailor agile practices to suit our needs; however, one must careful while doing so. Agile practices have been crafted into a delicate web of interdependent practices and disturbing one can affect other practices. We should be adept at using agile practices before we make any modifications. It might be tempting at times to blame the tools if our work is not going accordingly when the real problem lies in us. We should carefully examine our motives to change practices before we make any alterations.

Agile Estimation: Unveiling the Effectiveness of Story Points

Story point estimates are a way of estimating Agile projects. Story points are calculated using known tasks as a frame of reference to estimate other tasks. For example, if a task such as creating an input screen, for which we already know the amount of effort required to complete, has been assigned 3 points, we use it as a frame of reference to estimate other tasks based on their perceived complexity. While the estimation of backlog items and tasks is intended to reflect a combination of characteristics such as complexity, effort, and time needed to complete, most customers and many Product Owners focus on the time needed to complete. For them, time is money and hours are the preferred unit of estimation.

So, what makes story points better than hours for estimating Agile tasks and Product Backlog items?

Adaptive planning is a key practice in Agile methodologies. This implies that extensive estimating in terms of hours, which is time-consuming at the beginning of a project, is not an ideal practice on Agile projects. It is a daunting task to estimate at the beginning of a project. Determining the number of hours required even before any work has started, can not only be difficult but can also be riddled with inaccuracies. It is also difficult to foresee the impediments that arise during the course of the project.

Factoring time required to overcome any possible obstacles can make the estimates seem inflated to customers and Product Owners. This is especially true because time is seen as money, and quick mental calculations are being made to determine the “actual cost” of the project being performed. Inaccuracies in the opposite direction can arise when team members are asked to estimate of how long a certain task will take them, and they try to mitigate a customer’s possible objections to high costs by underestimating the time required. Since the premise of Agile and Scrum is to deliver value, and value is most often defined as the functionality the customer wants, the equation of time and money becomes counter-productive. The value of a particular working program is derived from what it will do for the customer not from how long it took to write it.

Story points reduce the effort spent on estimation so that we can get the project off the ground as quickly as possible. When asked to give an estimation in story points, the team member knows that the answer they give will not be immediately translated into dollars and cents. The motivation for the estimation is to accurately assess its complexity, effort, and resultant time in order to assign it a point value. There is no mixed motive trying to guess and allay assumed monetary objections.

Using hours for estimation can make it difficult to relate to the progress of the project, especially since they are the same units used to measure our workweeks. For example, if a team completes 200 hours of work in one week and 150 hours of work in the next, some might perceive that the team is slacking, even though the fewer hours might be due to the complexity of the tasks or to other non-project related activities such as meetings. Story points estimate the size of the story and do not necessarily have to be linked with the number of hours that might be required to complete it.

For ease of use, protection against biased motives, and clarity of expectation, story points are more useful—better—than hours for estimating Agile tasks and Product Log items.

Agile project management emphasizes flexibility, collaboration, and customer satisfaction. Agile estimation involves iterative processes where teams use techniques like story points, planning poker, and t-shirt sizing to estimate effort and time. This approach allows for more accurate predictions and adaptability, ensuring continuous delivery of valuable software aligned with customer needs.

Agile project management for testers, as advocated by SCRUMstudy, emphasizes a dynamic and iterative approach to software development. Testers play a crucial role within Agile teams, ensuring that each sprint delivers high-quality, tested increments of functionality. By collaborating closely with developers and stakeholders throughout the sprint cycles, testers contribute to early defect detection, rapid feedback loops, and continuous improvement. This iterative process not only accelerates delivery but also enhances product quality, aligning with Agile principles of flexibility, customer collaboration, and responsiveness to change. SCRUMstudy's framework equips testers with methodologies like Scrum, enabling them to adapt quickly to evolving project requirements while maintaining a focus on delivering value to end-users efficiently and effectively.

In Agile project management, testers operate within a framework that values iterative development and adaptive planning. They engage in frequent testing cycles to validate functionality and identify potential issues early on. This proactive approach not only ensures that software meets user requirements but also allows for timely adjustments based on feedback. Testers collaborate closely with cross-functional teams, contributing their expertise to continuous integration and deployment processes. By embracing Agile methodologies like Scrum, testers not only improve team efficiency but also foster a culture of collaboration and innovation in software development.

Ultimately, Agile project management empowers testers to deliver high-quality software that meets evolving customer needs. By emphasizing flexibility, transparency, and constant improvement, Agile frameworks like Scrum enable testers to streamline workflows, minimize risks, and enhance overall project success. SCRUMstudy's commitment to Agile principles equips testers with the tools and mindset needed to navigate complex project landscapes with confidence, ensuring that software products are not only functional but also reliable and responsive to market demands.

Scrum Agile Estimation, a fundamental aspect of Agile project management. Providing teams with a structured approach to estimating effort, time, and resources required for project activities. The guide emphasizes the importance of collaborative estimation techniques such as Planning Poker, which foster consensus and transparency among team members. By leveraging historical data, expert judgment, and team input, Scrum teams can generate accurate and reliable estimates that inform decision-making and mitigate project risks. The SBOK™ Guide also highlights the iterative nature of Agile estimation, encouraging teams to continuously refine and adjust their estimates based on evolving project dynamics. Through techniques such as Relative Estimation and Story Points, teams can effectively prioritize and plan their work, ensuring that they deliver value to stakeholders in a timely manner. By embracing the principles outlined in the SBOK™ Guide, organizations can cultivate a culture of trust, accountability, and predictability, driving successful outcomes in Agile projects.

Scrum Estimation is a collaborative process within the Scrum framework used to predict the effort required to complete work items. It involves assigning relative size or effort to user stories, tasks, or features to facilitate planning and prioritization. Unlike traditional time-based estimation, Scrum uses techniques like Story Points or Planning Poker, where the team collectively determines the complexity and effort required for each item. This approach encourages team consensus, transparency, and adaptability, allowing for more accurate forecasting and better decision-making during sprint planning. Scrum Estimation promotes continuous improvement by enabling teams to reflect on past performance and adjust their estimations accordingly, ultimately fostering a more efficient and productive development process.

Out of several estimation techniques involved in Scrum, few are noted below.

1. Wideband Delphi
2. Planning Poker
3. Fist of Five
4. Affinity Estimation

Wideband Delphi

Wideband Delphi is a group-based estimation technique for determining how much work is involved and how long it will take to complete the work. Individuals within the team anonymously provide estimations for each item and the initial estimates are plotted on a chart. The team then discusses the factors that influenced their own estimates and proceed to a second round of estimation. This process is repeated until the individual estimates are close to each other and a consensus for the final estimate can be reached.

Planning Poker

In Planning Poker, each team member is assigned a deck of cards. Each card is numbered in sequence with each number representing the complexity of the User Story (or task) in terms of time or effort. The Scrum Team members assess the User Story (or task) to better understand it. If there is no consensus, then the team members discuss reasons for selecting different cards or estimates. After this discussion, each member picks a card again. This sequence continues until all the assumptions are understood, misunderstandings are resolved, and a majority or consensus is reached. Planning Poker advocates greater interaction and enhanced communication among Scrum Team members. It also facilitates independent thinking by participants, thus avoiding the phenomenon of group think.

Fist of Five

Fist of Five is a simple and fast mechanism that can be used as an estimation tool, as well as a general group consensus-building technique. After an initial discussion about a particular User Story (or task) being estimated, Scrum Team members are each asked to vote on a scale of one to five using their fingers, with the number of fingers indicating the relative estimate value. Team members with outlier estimates (i.e., the highest and lowest values) explain their rational for their estimates to the group and these are discussed. After this discussion, another Fist of Five round is conducted or a collective decision is made.

Affinity Estimation

Affinity Estimation, such as T-shirt sizing, is a technique used to quickly estimate a large number of User Stories. Using sticky notes or index cards and tape, the team places User Stories on a wall or other surface, in order from small to large. Each team member begins with a subset of User Stories from the Prioritized Product Backlog to place in order by their relative size. This initial placement is done in silence. Once everyone has placed their User Stories on the wall, the team reviews all of the placements and can move User Stories around as appropriate. This second part of the exercise involves a discussion about the placements. Finally, the Product Owner will indicate some sizing categories on the wall. These categories can be small, medium, or large, or they may be numbered using story point values to indicate relative size. The team will then move the User Stories into these categories as the final step in the process. Some key benefits of this approach are that the process is very transparent, visible to everyone, and is easy to conduct.

Agile estimation tools are essential in project management, facilitating accurate and efficient planning in iterative development cycles. These tools, such as Planning Poker, T-shirt Sizing, and the Fibonacci sequence, help teams estimate the effort and complexity of tasks collaboratively. By promoting consensus and leveraging collective team insights, they ensure more reliable forecasts and enhance flexibility in adjusting to changing requirements. Agile estimation tools also support continuous improvement and transparency, enabling teams to track progress and make informed decisions throughout the development process.

Agile integration tools are essential for seamless collaboration and efficiency in Agile environments. These tools facilitate communication, automate workflows, and integrate various development and project management systems. By streamlining processes and enhancing transparency, Agile integration tools empower teams to deliver high-quality products faster, ensuring continuous improvement and alignment with business goals.

Agile Master Practices encapsulate principles and methodologies essential for effective Agile project management. These practices encompass a dynamic approach to project execution, emphasizing collaboration, adaptability, and continuous improvement. Key practices include fostering open communication within cross-functional teams, promoting iterative development cycles, and embracing change as a catalyst for innovation. Additionally, Agile Master Practices advocate for transparent decision-making processes, empowering teams to self-organize and take ownership of project outcomes.

Scrum agile practices encompass a set of principles and methodologies aimed at promoting flexibility, collaboration, and continuous improvement within project management. Key practices include iterative development cycles known as sprints, typically lasting two to four weeks, during which teams deliver incremental pieces of working software.

Project Management Institute’s “PMI Agile Certified Practitioner Exam Content Outline” organizes the tasks practitioners do when working in Agile environment into six domains. Their exam does not test specifically on the domains, so learning their grouping of tools and techniques and knowledge and skills will not be directly applicable to the language of the test. However, this organizational way of looking at Agile tools and tasks has been done to help practitioners learn and understand Agile better.

The six domains of Agile are:

• Value-driven delivery
• Stakeholder engagement
• Boosting team performance
• Adaptive planning
• Problem detection and resolution
• Continuous improvement

Let’s discuss each domain in more detail.

Value-driven delivery

Creating value is at the core of any project, and Agile methods are designed with the core objective of delivering value on a knowledge worker project. While maximizing value, Agile also has tools and techniques to minimize risks that can erode value. Agile methods also place importance on the customer’s priorities and is designed to deliver elements that have the highest value to the customer first.

Assessing value –.

Planning value – We create a charter detailing the scope, objective, and other attributes of the project. We then use tools such as customer-valued prioritization, relative prioritization, and risk adjusted backlog while preparing the priority list. Which planning value, we also assess the contracting costs of the project.

Delivering value – After planning how we are going to deliver value, we focus on eliminating all activities that do not add value. We can use task and Kanban boards to schedule the backlog. Limiting the Work in Progress (WIP) reduces the potential for reworking and keeps the project going smoothly.

Confirming value – We have executed tasks and created value but is this what the customer wanted? We have to confirm the value we are delivering to know this. We demonstrate prototypes, simulate functionalities to help the customer test the product and see how they work.

Tracking and reporting value – It is not enough that we just deliver value. It is important that we regularly track the rate of delivery of value so that it can be communicated to business stakeholders. Cumulative flow diagrams and burn down graphs are an easy and informative way through which we can assess the development of the project.

Stakeholder engagement

Stakeholders in a project can be anybody who can negatively or positively impact a project. They can be business representatives, customers, the project manager, the development team, or external vendors contributing directly or indirectly to the project. Stakeholder engagement becomes important, because software development involves creating intangible products and the team must have a precise understanding of customer requirements.

Agile projects are subject to constant change which makes it essential that a clear and steady channel of communication is established. All stakeholders must be involved in the project to ensure that it stays on the right track. Teams can use tools such as wireframes, user stories, a user story backlog, and personas to verify their understanding of customer requirements.

Face-to-face communication is the most preferred method of communication on agile projects. They provide the maximum amount of information in the least amount of time. Information radiators such as burn down charts, cumulative flow diagrams, and velocity tracking charts allow us to determine progress of the project, which can be communicated to all the stakeholders.

Soft skills play an important role while engaging with stakeholders. Soft skills such as negotiating and active listening are necessary while dealing with customers. It is also essential that we be familiar with implementing soft skills such as facilitation methods, participatory decision models, and conflict resolution that are primarily concerned with managing teams.

When we talk of managing teams, our leadership skills play a crucial role. Servant leadership is an extremely effective way of leading teams. A servant leader encourages the team to excel by removing any obstacles, motivate and reward the team’s performance.

Boosting team performance

The third domain in Agile deals with boosting team performance practices. In software development, “people factors” incur the highest cost. Therefore, it is extremely important that we obtain the highest return on performance.

The process of forming a team is one of the determinants of success on a project. Building a team goes through the stages of forming (identifying potential team members and bringing them together), storming (the team collaborates and comes up with ideas), norming (teams form rules and normalize their working patterns), and performing (the team works together). During each of these phases, it is important for a leader to know when to play a supporting or directing role. For example, during the storming phase, conflicts can be frequent and the leader will have to step in to help the team members develop methodologies to resolve them.

To get the best out of a team, it should be self-organizing and self-directing. Allowing teams to be self-organizing and self-directing enables team members to manage complex tasks by themselves and figure out the best way to complete the tasks. This capitalizes on the team’s combined expertise and talent.

There are several activities that can help a team boost their performance on Agile projects. Daily stand-up meetings are a quick way to communicate the team’s performance status and identify present and potential issues. To overcome issues and improve continuously, teams might need to be mentored at different stages. During events such as iteration planning meetings or retrospectives, teams might need to be coached at a group level and mentoring can be provided for individual team members when the iteration is underway.

Brainstorming sessions can be used by teams to resolve issues, improve, and innovate processes. Because face-to-face communication is the ideal way to communicate on Agile projects, it is important that the team be located in a common area with space for whiteboards and other information radiators.

Adaptive Planning

Because extensive planning before the project is undertaken can be cumbersome and often does not add any real value, Agile calls for an adaptive approach to planning. Adaptive planning involves creating a basic plan and updating it as the project gets underway. Adaptive planning requires practitioners to maintain close collaboration with the customer to understand his or her requirements more accurately. Collaborative games such as remember the future, prune the product tree, buy a feature, and bang-for-the-buck can be used to help the development team understand customer requirements better.

To make timely deliveries, team members should calculate their estimates as accurately as possible factoring in all diversions and constraints. Wideband Delphi and Ideal Time are some of the techniques which can help teams arrive at an accurate estimate. While estimating the cost of the project, the figures should be presented in ranges as they seem more credible than pin-point figures that can have an air of false confidence.

Iteration and release planning is a vital part of adaptive planning. Releases are bundles of functionality that can be delivered to a customer. While planning a release, the Product Owner/manager, development team, and Agile Expert can use a velocity chart to determine how many features can be completed by the team in a given time.  While planning iterations, it important to have a fixed priority list at the beginning of the planning session. Team members have the final say on how much work can be completed, while the product owner gets the final say on the priority of the items included for the iteration. Availability of team members needs to be factored in while planning iterations.

Problem Detection and Resolution

A common saying is, “A stitch in time saves nine,” and this couldn’t be more apt to explain how Agile methods deal with problems. If ignored, problems can have a devastating effect on the project as they not only increase the burden of rework; they make the team fall behind in its plans. It is a double whammy for the team when this happens as it takes twice the resources. Agile practices aids in detecting problems as early as possible and fixing them while they are still small.

Detecting problems is the first step to resolving them. Daily stand-up meetings are an excellent way to identify any issues that team members are facing.  Teams can also track issues by calculating cycle times for tasks. If the cycle time is too high, it might indicate a potential problem or that the team has undertaken more work than it can complete. Limiting work in progress can help monitor the project timeline better and track problems more easily. Despite our best efforts, some defects may make their way through to the final product. Escaped defects are the most expensive to fix. Teams can track escaped defects on a graph to analyze trends. This can help refine quality control processes.

Alistair Cockburn describes “failure modes and alternatives,” that are related to the human aspect of performance. Cockburn says that people fail because they can be inconsistent at following a technique, are creatures of habit and prefer to invent new ways than modify existing reliable methods. To counter “failure modes” Cockburn advises that teams should inculcate discipline, receive feedback regularly, and assign work based on personalities of individual team members.

Resolving issues that are identified is the next step. Continuous integration of new code, as and when it is developed, in a repository can help overcome the issues that we find with integration. Validating progress at frequent intervals and at different levels can help us be confident that our work is error-free.

In software development, commonly used techniques are Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD). These methods primarily involve writing the tests before any code is written. The codes are written until they pass the tests. Codes might then be “refactored” if necessary, which involves refining the design without altering its behavior.

Continuous Improvement

New insights and learning gained on a traditional project is typically gathered at the end of the project cycle. These insights might not be of much help on the next project unless the two are very similar. That learning could have had more value, if it had been used on the project in which it was learned. Agile methodology seeks to continuously improve throughout the project and encourage applying lessons to the development process as and when we learn it. Retrospectives at the end of each iteration makes the lessons learned available for the very next iteration.

A retrospective typically lasts for about two hours during which time the team gathers data about the different challenges that it faced and the various lessons learned while solving them. The learning is analyzed to see if there exists underlying patterns or any insights. Armed with these patterns and insights, the team plans the next iteration.

As part of continuous improvement, team members should be encouraged to share knowledge they acquire, with other team members. One of the reasons colocation is stressed in Agile projects is because it provides a platform for knowledge sharing through face-to-face communication. To encourage knowledge sharing, team velocity can be tracked at a team level rather than measuring it at an individual level, so that team members are motivated to help each other.

We might be required to tailor agile practices to suit our needs; however, one must careful while doing so. Agile practices have been crafted into a delicate web of interdependent practices and disturbing one can affect other practices. We should be adept at using agile practices before we make any modifications. It might be tempting at times to blame the tools if our work is not going accordingly when the real problem lies in us. We should carefully examine our motives to change practices before we make any alterations.

Story point estimates are a way of estimating Agile projects. Story points are calculated using known tasks as a frame of reference to estimate other tasks. For example, if a task such as creating an input screen, for which we already know the amount of effort required to complete, has been assigned 3 points, we use it as a frame of reference to estimate other tasks based on their perceived complexity. While the estimation of backlog items and tasks is intended to reflect a combination of characteristics such as complexity, effort, and time needed to complete, most customers and many Product Owners focus on the time needed to complete. For them, time is money and hours are the preferred unit of estimation.

So, what makes story points better than hours for estimating Agile tasks and Product Backlog items?

Adaptive planning is a key practice in Agile methodologies. This implies that extensive estimating in terms of hours, which is time consuming at the beginning of a project, is not an ideal practice on Agile projects. It is a daunting task to estimate at the beginning of a project. To determine the number of hours required even before any work has started, can not only be difficult but can also be riddled with inaccuracies. It is also difficult to foresee the impediments that arise during the course of the project.

Factoring time required to overcome any possible obstacles can make the estimates seem inflated to customers and Product Owners. This is especially true because time is seen as money, and quick mental calculations are being made to determine the “actual cost” of the project being performed. Inaccuracies in the opposite direction can arise when team members are asked to estimate of how long a certain task will take them, and they try to mitigate a customer’s possible objections to high costs by under-estimating the time required. Since the premise of Agile and Scrum is to deliver value, and value is most often defined as the functionality the customer wants, the equation of time and money becomes counter-productive. The value of a particular working program is derived from what it will do for the customer not from how long it took to write it.

Story points reduce the effort spent on estimation so that we can get the project off the ground as quickly as possible. When asked to give an estimation in story points, the team member knows that the answer they give will not be immediately translated into dollars and cents. The motivation for the estimation is to accurately assess its complexity, effort, and resultant time in order to assign it a point value. There is no mixed motive trying to guess and allay assumed monetary objections.

Using hours for estimation can make it difficult to relate to the progress of the project, especially since they are the same units used to measure our workweeks. For example, if a team completes 200 hours of work in one week and 150 hours of work in the next, some might perceive that the team is slacking, even though the fewer hours might be due to the complexity of the tasks or to other non-project related activities such as meetings. Story points estimate the size of the story and do not necessarily have to be linked with the number of hours that might be required to complete it.

For ease of use, protection against biased motives, and clarity of expectation, story points are more useful—better—than hours for estimating Agile tasks and Product Log items.

Agile Estimation: Unveiling the Effectiveness of Story Points

Story point estimates are a way of estimating Agile projects. Story points are calculated using known tasks as a frame of reference to estimate other tasks. For example, if a task such as creating an input screen, for which we already know the amount of effort required to complete, has been assigned 3 points, we use it as a frame of reference to estimate other tasks based on their perceived complexity. While the estimation of backlog items and tasks is intended to reflect a combination of characteristics such as complexity, effort, and time needed to complete, most customers and many Product Owners focus on the time needed to complete. For them, time is money and hours are the preferred unit of estimation.

So, what makes story points better than hours for estimating Agile tasks and Product Backlog items?

Adaptive planning is a key practice in Agile methodologies. This implies that extensive estimating in terms of hours, which is time consuming at the beginning of a project, is not an ideal practice on Agile projects. It is a daunting task to estimate at the beginning of a project. To determine the number of hours required even before any work has started, can not only be difficult but can also be riddled with inaccuracies. It is also difficult to foresee the impediments that arise during the course of the project.

Factoring time required to overcome any possible obstacles can make the estimates seem inflated to customers and Product Owners. This is especially true because time is seen as money, and quick mental calculations are being made to determine the “actual cost” of the project being performed. Inaccuracies in the opposite direction can arise when team members are asked to estimate of how long a certain task will take them, and they try to mitigate a customer’s possible objections to high costs by under-estimating the time required. Since the premise of Agile and Scrum is to deliver value, and value is most often defined as the functionality the customer wants, the equation of time and money becomes counter-productive. The value of a particular working program is derived from what it will do for the customer not from how long it took to write it.

Story points reduce the effort spent on estimation so that we can get the project off the ground as quickly as possible. When asked to give an estimation in story points, the team member knows that the answer they give will not be immediately translated into dollars and cents. The motivation for the estimation is to accurately assess its complexity, effort, and resultant time in order to assign it a point value. There is no mixed motive trying to guess and allay assumed monetary objections.

Using hours for estimation can make it difficult to relate to the progress of the project, especially since they are the same units used to measure our workweeks. For example, if a team completes 200 hours of work in one week and 150 hours of work in the next, some might perceive that the team is slacking, even though the fewer hours might be due to the complexity of the tasks or to other non-project related activities such as meetings. Story points estimate the size of the story and do not necessarily have to be linked with the number of hours that might be required to complete it.

For ease of use, protection against biased motives, and clarity of expectation, story points are more useful—better—than hours for estimating Agile tasks and Product Log items.