Agile has become the go-to framework for managing software development and other project workflows due to its emphasis on flexibility, collaboration, and rapid iterations. However, despite its advantages, Agile sometimes lacks the detailed metrics necessary for evaluating the lifetime and quality of a task. Hence, I decided to write the FPSE method.
The Four Points Scale Estimation (FPSE) Method aims to fill this gap by introducing a granular evaluation process that measures a task’s lifetime across critical stages. This article explores the FPSE method idea, detailing its core principles, scoring mechanisms, practical applications, and how it can foster continuous improvement within Agile teams.
The FPSE method was designed to measure not just the completion of tasks, but how efficiently each task moves through the Agile pipeline. By focusing on task lifetime and task quality, FPSE offers a much more detailed assessment of team performance, helping managers and teams identify areas for improvement
Agile is a widely adopted project management methodology, primarily used in software development, but also applicable in various industries. Agile promotes flexibility, adaptability, and continuous improvement. Its key philosophy revolves around the idea of delivering incremental value rather than waiting for an entire project to be completed before seeing results. Agile values collaboration between cross-functional teams, with a focus on quick delivery and responding to change.
Agile frameworks such as Scrum and Kanban help structure this approach, enabling teams to break down large, complex projects into smaller, more manageable tasks that can be completed within short timeframes known as sprints or iterations. These smaller pieces of work are often referred to as user stories or story points, which describe the value a task provides from the user's perspective.
Agile typically operates on a cycle that repeats with each sprint, allowing teams to assess their work, gather feedback, and adapt accordingly. Below are the key stages within an Agile process:
At the beginning of each sprint, teams hold a planning meeting to define the scope of the work that will be tackled in the sprint. During this stage, the team selects user stories or tasks from the backlog (a prioritized list of all the work needed to be done). The team estimates the effort required for each task, typically using Story Points (SP) as a measure of complexity or effort.
Once planning is complete, teams move into the Design phase. During this stage, the team discusses the specific details of each user story or task, designing the technical and user experience aspects needed to complete the task successfully. The design phase is crucial for aligning the team on the solution before development begins.
In the Development stage, the team builds the actual solution or feature based on the design. Developers, engineers, or team members execute the tasks assigned during the sprint, writing code or creating solutions. Development is an iterative process, where team members continuously check in their work and collaborate to ensure that all pieces of the solution come together.
Once the task has been developed, it moves to the Testing phase. This is where quality assurance takes place. The team tests the solution to ensure it functions as intended, without bugs or issues. The testing phase can include unit testing, integration testing, or user acceptance testing.
If everything goes well in the other stages, you deploy and deliver your product to the customer.
After testing and deploying, the solution enters the Review stage, where it is assessed for final approval of finishing what you started. Team members, stakeholders, users, or the product owner review the completed work to ensure it meets the requirements and delivers the expected value. Any feedback or required changes are discussed, and the team decides whether the task is complete or needs further adjustments.
Rework During Development: A poorly designed task may require developers to redo large portions of work, delaying the overall progress.
Testing Bottlenecks: If bugs or issues are found late in the process, tasks may be sent back to development, extending the task lifetime.
Stakeholder Delays: The review phase, which often depends on external stakeholders, can create delays if feedback is slow or unclear.
The Four Points Scale Estimation (FPSE) method evaluates a task’s performance by assigning points at each phase of the Agile process. The scoring reflects how efficiently the task moved through each phase, with delays or rework resulting in higher scores (which are undesirable), while smooth transitions between phases result in negative scores (which are desirable).
The key differences are:
Unlike Agile, which primarily measures progress in terms of iterations and story points, the FPSE Process tracks the entire lifecycle of a specific task from its inception to completion, with a strong emphasis on avoiding rework or delays.
FPSE assigns each task a score based on how efficiently it progresses through stages (Design, Develop, Test, Review). Agile lacks such a scoring system, meaning teams have little quantitative insight into how quality is being maintained over time.
Agile encourages flexibility but doesn’t penalize tasks for needing extra time or revisions. FPSE directly holds tasks accountable by adding points for delays, rework, and postponement. This provides a direct link between a task’s lifecycle and its final score, promoting better planning and quality control.
The FPSE Process focuses on ensuring that each stage of a task (Design, Develop, Test, Review) is completed thoroughly, rewarding teams that avoid repetition. By calculating a weighted average score for each sprint, FPSE allows teams to identify recurring issues that affect task quality and work efficiency. Agile, on the other hand, typically focuses on speed without giving as much direct attention to quality control at the individual task level.
FPSE makes it easy to identify which phases of the process are causing delays. For example, if multiple tasks receive high scores during the testing phase, it may indicate a problem with the testing process, such as insufficient test automation or a lack of skilled testers.
By emphasizing penalties for rework and delays, the FPSE Process encourages teams to focus on quality from the outset. Ensuring that each stage is completed thoroughly helps avoid issues down the line, leading to better project outcomes.
Teams can use the weighted average score to assess performance over time. This data-driven approach allows teams to identify areas for improvement and refine their processes for future sprints.
The FPSE method offers a more objective measure of task completion than traditional Agile metrics. Instead of relying on subjective estimates or qualitative feedback, FPSE assigns quantifiable scores to each phase, providing a more accurate picture of team performance.
In the FPSE Method, each task goes through the following four stages. This framework provides clear milestones that allow teams to monitor progress, assess quality, and track the overall task lifetime. This method removes the Plan and Deploy stages of the Agile method, these stages focus more on the whole process of the product and the work that lets you understand why and how to plan the tasks.
The Design phase involves defining the task, clarifying requirements, and ensuring that the team has a clear vision of the expected outcome. Proper design is critical for the success of any task since it sets the foundation for all subsequent stages.
Importance: A well-designed task ensures fewer delays and iterations later in the process. A failing Design phase can indicate issues in how meetings are managed or reveal misunderstandings about the task or the product. Managers and team leaders need to ensure that they have a solid grasp of both the task and the overall product to avoid design-phase pitfalls.
The Develop stage is where the actual work takes place. Development involves building the solution or product based on the specifications outlined in the Design phase.
Importance: Quality development is vital to avoid technical debt and costly rework. Properly executing this stage results in a reduced score, while repeated work causes penalties. If the Develop phase shows inefficiencies, it may signal deeper issues within the development team or indicate that the Design phase was not properly executed.
Testing is essential to ensure that the developed solution works as intended and meets all requirements. Quality assurance is vital at this stage, with the goal being to uncover issues before they affect the end user.
Importance: High-quality test coverage reduces the chance of errors in production, minimizing the need for costly rework. If problems arise during the Test phase, it often points back to flaws in the development process or poor task characterization during the Design phase.
In the Review stage, the task is examined for final approval. Stakeholders assess whether the work meets expectations and if any changes are required.
Importance: A thorough review ensures that the task meets the required standards before it is marked as complete. If the Review phase reveals issues, it may necessitate revisiting earlier stages and indicate problems in understanding the product, inadequate characterization, or poor execution in development and testing.
The FPSE Process uses a simple yet effective Four Points Scale to score tasks. This scale ranges from -4 (best) to +4 (worst), with each point on the scale representing how efficiently a task progresses through the four stages of the FPSE Process.
Every task begins with a score of zero. As the task moves through its stages, points are either added or subtracted based on whether the task progresses smoothly, or encounters delays and rework.
Every time a stage is completed successfully, the task moves on to the next and lower phase (from Design to Develop, from Develop to Test, from Test to Review, from Review to Finished). one point is subtracted from the task’s score. If all stages are completed without issues, the task reaches a score of -4, which represents the best possible outcome, indicating a high-quality task that was efficiently completed.
Two points are added if a stage needs to be revisited, and the task is going up and back in the hierarchy. Repeating a stage signals inefficiencies or miscommunications that affect the quality of the task.
Two points are added if the task is delayed, needs additional Story Points (SP), or is postponed to a future sprint. This indicates a failure to complete the task as initially planned.
A task will automatically receive a score of +4 points if it is carried over to the next sprint. This reflects poor sprint planning or highlights deeper issues with tasks that had high scores, leading to delays. The automatic penalty is a clear signal that either the sprint was overestimated or certain problematic tasks impacted the timeline, pushing the affected task to the next sprint.
Once a task leaves the current sprint, its score is finalized based on the progress and quality of the work completed. A higher score reflects inefficiencies, delays, or the need for rework, while a lower score signifies that the task was completed efficiently and with high quality. The goal is to minimize task scores, learning from any mistakes and ensuring smoother processes for future sprints.
When a task reaches a score of positive four in the FPSE system, it's a clear signal that the task has hit a major roadblock and must be stopped immediately. Rather than pushing forward and wasting more time and resources, this is the moment to pause and reflect. Take a step back and thoroughly analyze the task’s journey—identify where things went wrong and why the task accumulated so many points. This evaluation shouldn't just focus on the current task but should offer insights and lessons that can be applied to future projects as well.
A task with a score of four is marked as incomplete, and no further effort should be put to salvage it. Instead, terminate the task, consider it finished, and create a new task with the same goal but a clearer understanding of what went wrong and how to improve.
To effectively assess task quality and project performance, several weighted scoring methods can be utilized. These methods provide a quantitative way to evaluate how well tasks are executed and help identify areas for improvement.
The Weighted Average Grade offers a broad perspective on task quality over a defined period, such as a sprint or quarter. This average integrates scores from various tasks, adjusting for their relative importance or impact.
Application: To calculate the Weighted Average Grade, assign weights to tasks based on their complexity or significance. Multiply each task’s score by its weight, sum these values, and then divide by the total weight. This provides an average that reflects both task performance and its impact on the overall project.
The Weighted Sprint Score evaluates the overall efficiency and quality of tasks completed during a sprint. Each task’s score is adjusted for its complexity (amount of story points), providing a more accurate measure of the team’s performance within that sprint.
Application: To calculate the Weighted Sprint Score, use the same method as for the Weighted Average Grade but focus specifically on tasks from a single sprint. This score helps in assessing the effectiveness of sprint planning and execution.
The Weighted Quarter Score assesses performance over a quarter, providing insights into longer-term trends and overall project health. It aggregates scores from multiple sprints or tasks within the quarter, weighted by their significance.
Application: To determine the Weighted Quarter Score, calculate the weighted average of all tasks completed in the quarter. This score helps in evaluating quarterly performance and strategic planning.
Example: If a quarter includes several sprints with tasks of differing weights, aggregating and averaging these scores provides a comprehensive view of quarterly performance.
The Weighted Product Process Score evaluates the entire product development process, focusing on stages such as design, development, testing, and review. This method helps in evaluating the product's lifecycle.
Application: Assign weights to different tasks of the development process based on their weight on the product. Calculate the weighted average of scores from each task to assess the overall effectiveness of the product development process up to the current time and phase.
The Weighted Category Score assesses specific categories or types of tasks, such as critical vs. non-critical tasks, or tasks of different departments. This method helps in understanding how different categories contribute to overall project performance.
Application: Assign weights to different categories of tasks and calculate the average score for each category. This provides a clear picture of how various task categories perform and helps in prioritizing areas for improvement.
It needs to be clear that we are humans and that the quarter or even sprint score will probably never be a perfect negative four, but we will always try to get as much perfect tasks that we could be.
A perfect score probably shows a bad thing about the management and it needs to be fixed up. Scenarios that could be when a perfect score:
You Avoid Taking Risks: If every task achieves a perfect score, it could indicate that the team is playing it too safe, avoiding any risks that might lead to innovation. Risk-taking is essential for growth, and avoiding challenges might limit the team's potential for improvement or creativity.
You lie: Consistently reporting perfect scores could mean that data is being manipulated or inaccurately reported to give the illusion of flawless task execution. Honesty in reporting task completion is crucial for genuine improvement.
You don’t know math: But let's assume you know… so it's probably one of the above.
In the pursuit of perfection, it’s essential to focus on meaningful progress rather than an idealized, unattainable outcome. True improvement comes from learning from mistakes, addressing inefficiencies, and taking calculated risks to drive innovation.
Task A involves adding a simple login feature to a website. The team progresses smoothly through all stages: the design is clear, development occurs without errors, testing reveals no bugs, and the review process is efficient. This is a model task that achieves a perfect score.
Design: Requirements were well-defined and caused no issues in the development phase.
Score: -1
Development: The task was completed on time without errors or need for rework.
Score: -1
Testing: No bugs or issues were identified during testing.
Score: -1
Review: Stakeholders quickly approved the task without requesting any changes.
Score: -1
Final Score: -4 (Perfect task lifetime)
This task progressed through all stages without any delays or quality issues, achieving the ideal score of -4.
Task B completes the Design and Develop phases smoothly but faces significant issues during the Testing phase. The task requires rework, going back to both the Design and Develop stages before testing again. This rework adds six points to the task's score.
Design: Initial design was thought to be clear, and the phase was completed smoothly.
Score: -1
Development: Development was completed on time and moved forward to testing.
Score: -1
Testing: Major issues were discovered, requiring changes in both design and development.
Score: 0
Design (2nd Pass): The design was revisited to address the issues and completed again.
Score: +1 (+2 for rework, -1 for moving forward)
Development (2nd Pass): Development completed with the necessary fixes.
Score: +1 (+2 for rework, -1 for moving forward)
Testing (2nd Pass): No bugs were found in the second round of testing.
Score: +1 (+2 for rework, -1 for moving forward)
Review: Stakeholders approved the task with no further changes.
Score: -1
Final Score: 0
This score indicates delays and inefficiencies, with rework needed in multiple stages. Although the task was completed, it encountered issues that increased the score.
Task C moves smoothly through the Design and Develop stages but is postponed to the next sprint before entering Testing. This results in an automatic score of +4, signaling problems with either sprint planning or an overload of other problematic tasks.
Design: Clear requirements led to a smooth design phase.
Score: -1
Development: The task was completed and ready for testing.
Score: -1
Postponed: The task was delayed and moved to the next sprint without completing the remaining phases.
Automatic Score: +4
Final Score: +4
This postponed task signals a problem with sprint planning or prioritization, requiring a review of how tasks are allocated in the sprint.
Task D proceeds through the Design and Develop stages, but during Testing, significant bugs are found. After multiple attempts to fix the issues in Development, the task repeatedly fails testing and accumulates a score of +4, at which point the task is recommended for termination.
Design: Requirements seemed clear, and the design phase was completed.
Score: -1
Development: Initial development was completed on time and sent for testing.
Score: -1
Testing: Major bugs were found, requiring rework in Development.
Score: 0
Development (2nd Pass): Development was revised to address the issues.
Score: +1 (+2 for rework, -1 for moving forward)
Testing (2nd Pass): The same bugs persisted, requiring further changes.
Score: +1 (+2 for rework, -1 for moving forward)
Development (3rd Pass): Development was revised again to address the remaining issues.
Score: +1 (+2 for rework, -1 for moving forward)
Testing (3rd Pass): The bugs were still present, preventing progress.
Score: +1 (+2 for rework, -1 for moving forward)
Final Score: +4
At this stage, the task is recommended for termination due to ongoing issues that cannot be resolved. The team should assess what went wrong in both the design and development stages and apply the lessons learned to future tasks.
The FPSE method is designed to be adaptable, though it primarily focuses on the lifecycle of software development tasks. However, different industries or types of projects may have unique phases that are crucial to their task-completion process. If you feel a certain phase should be added to or replaced in the lifecycle hierarchy, the FPSE system can accommodate that, provided a few simple rules are followed:
Before adding a new phase, ask yourself if it truly represents a distinct phase, or if it's just a subcomponent of an existing phase. The new phase should have a meaningful impact on the overall outcome of the task. If omitting this phase would negatively affect the task’s success, then it’s appropriate to include it.
If you feel the need to replace an existing phase with another, first assess whether the current phase you’re removing is genuinely unnecessary. Will its removal have a negative effect on the task’s final outcome? If so, it’s a red flag and the phase probably should remain. Additionally, when adding the new phase, consider whether it will impact the results similarly to the way new phases are introduced. Finally, verify that this replacement improves the clarity and effectiveness of the lifecycle.
Once you’ve added or replaced phases, it's time to adjust the scale to reflect the new lifecycle. If you’ve added a phase, extend the scoring system accordingly. For example, if there are now five phases instead of four, your score range should be expanded from -4 and +4 to -5 and +5. The same logic applies for adding or removing phases. Each phase should adjust the scoring scale in a balanced manner.
Even after customization, the core principles of FPSE remain the same. The goal is to track the quality and lifecycle of tasks while ensuring efficiency, and any customization should continue to reflect this overarching purpose.
In summary, while FPSE is adaptable to different industries and project types, changes to the lifecycle hierarchy should be made with careful consideration to ensure they enhance the effectiveness of task management and evaluation.
Before implementing FPSE, it's crucial to establish a solid foundation. Begin by setting up the necessary resources to track FPSE scores, preparing your team for the new evaluation process, and customizing the FPSE scale to suit your specific workflows. Collect baseline metrics to understand your current performance. Track how long tasks are spent in each phase of the Agile pipeline and pinpoint areas prone to delays or rework. These insights provide a starting point to measure progress effectively.
As tasks progress through the Agile workflow, assign FPSE scores at each phase. For example, after completing the development phase, evaluate whether the task advanced smoothly or encountered rework or delays. Assign a positive or negative score based on the task’s performance and quality during that phase. Consistent scoring ensures that each task contributes meaningful data for analysis.
After every sprint, analyze the FPSE scores for all completed tasks. Look for recurring patterns or trends. Are delays concentrated in specific phases? Do certain task types consistently score higher, like complex features or high-priority bugs? These insights reveal bottlenecks and areas for improvement.
Use FPSE data to inform actionable changes to your workflow. For instance:
If testing frequently receives high scores, consider investing in advanced test automation tools or increasing QA resources.
If the design phase causes delays, refine your requirements-gathering process or involve designers earlier in the workflow.
These adjustments ensure your team addresses inefficiencies systematically, enhancing overall productivity and quality.
At the end of the day, your main purpose is to ensure you get each task and sprint with the lowest score possible. Therefore, encourage teams to set measurable improvement goals based on FPSE scores. For example, a team might aim to reduce the average task score from +3 to +1 over the next three sprints. This fosters a culture of continuous improvement, motivating teams to enhance task quality and reduce inefficiencies incrementally.
The FPSE method provides a powerful tool for Agile teams looking to improve both the efficiency and quality of their work. By offering granular feedback on each phase of the task lifecycle, FPSE allows teams to identify bottlenecks, allocate resources more effectively, and prioritize quality over speed.
In today’s fast-paced development environments, where continuous improvement is key to success, FPSE offers a structured, data-driven approach to refining workflows and delivering higher-quality outcomes. Agile teams that adopt FPSE can expect to see not only improved velocity but also higher customer satisfaction, as tasks are completed more efficiently and with fewer errors.
By making quality and task lifetime visible through the FPSE lens, teams can achieve the true spirit of Agile: delivering value faster and with greater reliability.