The Use Case for Not Using Use Cases
Use Cases, Epics, Stories, Story Points may not be the best way to estimate IT project effort.
Accurate project estimation is crucial for the success of any IT project. It helps project managers and stakeholders to understand the time, cost, and resources required to complete a project. However, estimating the number of hours for an IT project using story points, use cases, and Epics can be challenging due to several limitations.
Subjectivity
Task effort is often measured subjectively using story points, use cases, and Epics. These measures depend on the personal experiences and viewpoints of the team members involved in the estimation process.
Complexity
IT projects can be complex, involving many interdependent tasks and components. It's difficult to estimate the effort required for each task or element in isolation accurately, and the relationships between tasks can significantly impact the overall project timeline. Story points, use cases, and Epics may not adequately capture this complexity, leading to inaccurate estimates.
Team Dynamics
A team's effectiveness in working together and ability to handle project tasks can significantly impact the project timeline. Story points, use cases, and Epics may not adequately account for the team's dynamics, leading to inaccurate estimates.
The Path Forward
One effective method is implementing a data-driven system leveraging historical project data and machine learning algorithms. The project estimator can create a more accurate prediction model by analyzing past projects, their complexities, and actual completion times. This approach involves creating a comprehensive database of completed tasks, including their initial estimates, the actual time taken, and various attributes such as technology stack, team size, project type, technical complexity, the process maturity of the project team, and the tools used in the project (with an understanding that GenAI will disrupt this calculation).
A better measurement
Knowing what will be produced in an IT project is the cornerstone of an accurate project estimate. However, the subjectivity of epics, stories, story points, and use cases can result in varying estimates and make it challenging to accurately predict the time needed for a project. To address this issue, a more objective approach to effort estimation is necessary.
A more effective approach might involve breaking down the project into smaller, more manageable tasks and estimating the time needed for each task based on the specific skills and experience of the team members involved.
Equipping the project team and the project estimator with a list of project outcomes and the tasks needed to meet these outcomes is paramount to accurately predicting the effort and duration required to succeed.
Introducing the Work Mapping Unit (aka WMU)
The Work Measurement Unit (WMU) serves as the quantitative building block of an estimate. A manifest of all WMUs is necessary and can be based on various components, including reports, conversions, enhancements, interfaces, data structures, transformations, config files, encounters, rules engine validations, orchestrations, diagrams, process configurations, forms, workflows, mediations, scripts, modules, objects, widgets, features, screens, templates, servlets, beans, classes, tables, views, database seeds, data loads, queries, and macros.
But we don’t know how many or what type of WMUs are needed
If your team cannot provide a manifest of WMUs to be accomplished in the project, stop estimating something the team cannot define or articulate in terms of effort.
It’s kind of like asking how long it will take to paint a house if you don’t know the size of the house.
Bottomline: Know the project’s outcome in terms of Work Mapping Units before committing to a fixed price or guaranteeing a set level of effort.
Ps. No AI was harmed while writing this note.